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INTRODUCTION 



The Operating System/360 Queued Telecommimi- 
cations Access Method (QTAM) provides macro 
instructions for specifying the operation of a 
communications-based data processing system. 
This book is a compilation of logic flowcharts and 
explanations designed to instruct the programmer in 
the use of these macros. In a tutorial manner, the 
reader is led through the necessary decisions in a 
workbook-like development of the system macro 
coding on the queued access method level. 

A sample program using QTAM is included in the 
Appendix along with some guidelines to designing 
message formats for efficient use of QTAM. 

Upon completing this book, the user will have 
completely specified and put together all the coding 
needed to perform the following functions: 

Polling and addressing of terminals 

Dialing and answering of terminals 

Allocation of core storage buffers 

Routing of messages 

Queuing of messages 

Header analysis and sjmthesis 

Message logging 

Error checking 

Error procedures 
Functions not provided for in this book are: 

Processing of message contents 

Formulating replies to inquiry messages 

Operator control of the commimications system 

This book is largely a presentation of information 
found in the SRL document IBM Operating System/360: 
Telecommunications (C28-6553). It is intended that 
the SRL document be a reference for further detail 
in specific areas. 

Prerequisites for using this book are: 

• Knowledge of a system configuration and its 
application-oriented operating procedures. 

• Layouts of the message formats that will be 
sent and received via communication lines. 

• An imderstanding of the principles of Operating 
System/360 (IBM Operating System/360, Concepts 
and Facilities, C28-6535). 

• A general, but not extensive, knowledge of the 
System/360 Assembly Language (IBM Operating 
System/360; Assembler Language, C28-6514). 



The QTAM macro coding produced with this book 
specifies the operation of a Message Control Task 
within the framework of Operating System/360. A 
Message Control Task encompasses all the communi- 
cations-oriented fimctions listed but does not include 
user programs to process the data content of messages 
received from commimications lines. The processing 
of the data content of the messages is performed by 
Message Processing Tasks that are user-provided 
and operated as separate tasks within Operating 
System/360. These Message Processing Tasks are 
not obtainable through use of this book. 

There is, however, the facility within QTAM to 
incorporate programs as subtasks of the Message 
Control Task in order to do a moderate amount of 
data processing. These subtasks will not then 
operate as separate tasks of the Operating System, 
and consequently will make it possible to operate in 
a task- restricted environment. 

Instruction is given at the appropriate points in 
this book for inclusion of such subtasks. The reader 
is again referred to C28-6553 for further description 
of the details and restrictions of such operation. 

The Message Control Task to be developed here 
consists of the following parts: 

Data set definition 

Control information 

Line procedure specification 

Data Set Definition is concerned with the writing of 
DCB (data control block) statements. These state- 
ments specify the operation of direct access storage 
devices, logging devices, and communication lines. 

Control Information is necessary for operation of 
ct>mmunication lines. It consists of terminal device 
information, polling list descriptions, and buffer 
assignments. 

Line Procedure Specification (LPS) uses standard 
delimiter and functional macros to provide the 
necessary logic flow for header analysis/synthesis 
and for message handling. 



This book breaks the above three main parts into Using this book to develop a Message Control 

the following sections: Task, the reader will proceed through each of the 

A. Communication Line Group DCB above sections as directed. As part of the job of 

B. Direct Access Storage Device Queue DCB progressing through a section, macro statements for 

C. Logging Device DCB that section are to be filled out. These macro state- 

D. Terminal Table ments will then be collected and ordered to form the 

E. Polling List three parts: Data Set Definition, Control Information, 

F. Buffers and LPS(s). These, in turn, are gathered to form 

G. Receive Segment the Message Control Task. 

H. Receive Header The first part to be considered will be Data Set 

J. End Receive Definition. Here we will be concerned with the 

K, Send Header writing of DCB macro statements. This is in 

L. Send Segment harmony with the control procedures for Operating 

M. End Send System/360. 

N. Data Set Initialization 

P. Structuring 



SECTION A. COMMUNICATION LINE GROUP DCB 



BEGIN 



Write "Section A. Communication Line Group DCEi" in the margin at the 
top of the first coding sheet. This will identify the macro statements for 
Section A. 



1 



Each communication line group in the system must have a statement defining its 
I characteristics. This is done with a Data Control Block (DCB) statement. (A 
j line group consists of all communication lines in the system that have the same | 
I channel programs, the same buffer requirements, the; same line procedure sped- i 
I fications, the same send-receive relative priority, the same polling intervals, ' 
I and the same type terminals.) I 



Choose symbolic names for each line group. Enter each name in a Name field 
of macro statements for this section. (Allow about two lines per statement.) 
Each of these statements will be a DCB statement — one for each line group. 



EXAMFIE DCB 



Name 


Operation 


Operand 


DCBGRUPl 


DCB 


DDNAME=DDGROUP, DSORG=CX, 






MACRF=(G,P),CPOLL=(POLLINEl, 






POLLiNE2),INTVL=5,BUFRQ=3, 






ACLOC=bb,CLPS=LPSl 



I From here on, the discussion will be per DCB. For nore than one DCB a | 

I similar procedure should be followed for each. l 

3 



Write DCB in the Operation field of the macro statement. 



i 



Write DDNAME = name in the Operand field, where name is the symbolic name 
for the line group that will be in the Data Definition Statement (DD card) for 
this line group. (DD cards are job control cards thcit will be prepared when the 
Message Control Task being written is entered into he Operating System for 
execution. There will be a DD card entered for every Data Set defined by a 
DCB statement in the Message Control Task.) 

Ex: DDNAME = DD GROUP 



I 



Use a comma to separate this and all future entries of the Operand field 



"1 



Write DSORG = CX as the next entry in the Operand field; CX identifies this 
statement as a communication line group DCB. 



i 



Write MACRF = (G,P) as the next entry in the Operand field. This allows the 
lines to operate at the GET/PUT level. 



i 



Write CPOLL = (x,y,z) in the Operand field, as the polling list names for all 
the lines in the line group, where x,y,z represent the polling list names of each 
line as specified by the POLL macro (section E.) Every line In the system must 
reference a polling list name, whether it actually has polled terminals on it or 
not. (An output-only or non-polled line will not have any terminal entries in 
the polling list specified by its POLL macro. The polling list name for such a 
line may be shared by all other similar lines.) These names are to be listed 
in the order specified in the Data Definition Statement, each one separated 
by commas and the list enclosed in parentheses. 

Ex: CPOLL=(POLLI NEl , POLLI NE2, POLLI NE5) 




No 



-►< 



Write in the Operand field INTVL=t, where t is the time delay desired between 
consecutive polling passes in seconds (t <255 ) for each line of the line groups. 

Ex: INTVL=5 



p. 3 



l^p.: 



p.2 



p.2 



Enter in thA Operand field fhe number of buffers(n) that are to be requested ahead 
for the buffering of each communications line. A value of n=2 will be assigned 
by the system if this parameter is omitted. This entry is written as BUFRQ = n. 
I Ex: BUFRQ = 3 



Enter in the Operand field the number of buffers(n) that are to be requested ahead 
for the buffering of each communications line. A value of n=2 will be assigned 
by the system if this parameter is omitted. This entry is written as BUFRQ = n. 
Ex: BUFRQ = 3 




Write CPRI = R as the next entry in the Operand field to indicate that Receive 
has priority over Send. 



■^H»^ 



Write CPRI = E as the next entry in the Operand field to indicate equal priority 
between Send and Receive 



Next write in the Operand field ACLOC=bb where bb represents two blank 
spaces that will be filled in after specifying the Terminal Table (Section D), 

Ex: ACLOC = bb 



I 



To identify the LPS (Line Procedure Specification) that will be specified for tWs 
line group (sections G-M), write the symbolic name of the LPS in the Operand 
field as: CLPS = d where d is the symbolic name. This LPS name is the same 
asthe name that will be used in the Name field of the LPSTART macro described 
in Section H. Ex: CLPS = LPSl 



^ — J - , 

I The section concerned with line group DCBs is completed. The next section will I 
I define the Direct Access Storage Device Queue DCB. I 



p.4 



SECTION B. DIRECT ACCESS STORAGE 
DEVICE QUEUE DCB 



p.3 



Is queuing of messages 
to be done on a Direct Access 
Storage Device (DASD) or in 

core storage (CORE)? 



CORE 



DASD 



No DCB is needed for o core storage data set. 



Write "Section B. Direct Access Device Queue DCB" in the margin at the top 
of the next blank coding sheet. This will dentify the macro statement for 
Section B. 



L 



[The Direct Access Storage Device used for queuing of the messages in the I 

[system must have a DCB statement defining its characteristics. | 



J. 



Choose a symbolic name for the Direct Access Device and enter it in the Name 
field of the first macro statement for this section. This will be the DCB statement. 

Ex: DCBFILE 




EXAMPLE DCB 




Name 


Operation 


Operand 1 


DCBFILE 


DCB 


DDNAME=DDFILE,DSORG=CQ, 1 






MACRFKCP) 1 



Write DCB in the Operation field of the macro statement. 



Write in the Operand field the symbolic name for the device that will be 
in its Data Definition Statement (DD card). 

Ex: DDNAME=DDFILE 





A comma must be used to separate this and all subsequent entries of the Operand 1 
I field. ^ I 



T' 



Write DSORG=CQ as the next entry in the Operand field, since this DCB 
statement is for a Direct Access Storage Device. 



Write MACRF = (G, P) as the next entry in the Operand field. This allows the 
DASD to operate at the GET/PUT level, 



:t 



I The section concerned with the Direct Access Storage Device DCB is I 

I completed. The next section will define the logging device. J 




SECTION C. LOGGING DEVICE DCB 



iClJpp.4,5 



I Messages are automatically retained when a Direct Access Storage Device is 

I used for the queuing of messages. In addition to this, messages may be logged 

I sequentially on a secondary storage device by use of the LOGSEG macro 

I instruction in the LPS. Use of the LOGSEG macro implies using the Queued 

I Sequential Access Method (QSAM), the operation of which will be taken 

' care of completely by QTAM. The message segments logged on this device 

I will be interleaved if more than one line uses the same device. 



1 





Write "Section C. Logging Device DCB" In the margin at the top of the 

next blank coding sheet. This will identify the macro statements for Section C. 



^,__. 

I Each secondary storage device used for the logging of messages in the system must I 
I have a statement defining its characteristics. This is done with a DCB statement | 
I for each specified logging device. I 



[T 



j NOTICE 

I The parameters of the Logging Device DCBs are subject to the requirements of I 

QSAM and are described here only to ensure their inclusion In the Message | 

I Control Task . The reader is referred to IBM Operating System/360: Control j 

I Program Services (C28-6541) for exact specification. i 



p.7 




Choose symbolic names for each logging device needed and enter them in the 
Name fields of the macro statements for this section. The symbolic names will 
be a parameter of the LOGSEG macro instructions issued in the LPS. Differ- 
ent LOGSEG macros may use the same symbolic name or different ones, 
depending on whether the same logging device is to be used. Each of the 
macro statements containing symbolic names will be a DCB statement — 
one for each logging device. 

Ex: LOGFILE 



EXAMPLE DCB 



Name 


Operation 


Operand 


LOGFILE 


DCB 


DD NAME=DD LOG , DSORG=PS, LRECL=95 






BLKSIZE=95,MACRF=(PM), 






RECFM=V, BFTEK-S, DEVD=TA, DEN=1 , 






TRTCH=T 



I Subsequent discussion for specification of the logging device DCB's will be for a \ 
I single logging device with the understanding that a similar DCB is needed for each. I 

T 



Write DCB in the Operation field of the macro statement. 



I 



Write in the Operand field the symbolic name for the logging device that will be 
in its Data Definition Statement (DD card) specified as DDNAME=name. 

Ex: DDNAME=DDLOG 



_1 

I A comma must be used to separate this and all subsequent entries of the Operand • 

liif'd: ^_ J 

.: ^ ! . 



Write DSORG=PS as the next entry in the Operand field, since this DCB 
statement is for a logging device. 



i 



Write LRECL=n as the next entry in the Operand field, where n is the maximum- 
length logical record to be written on the logging device. 



Write BLKSIZE=n as the next entry in the Operand field, where n is the 
maximum physical block length in bytes to be written on the logging device. 

Ex: BLKSIZE=95 



y 



Write MACRF = (PM) as the next entry in the Operand field. This allows the 
device to operate in the PUT and MOVE mode. 




Write RECFM = V as the next entry in the Operand field. This allows writing of 
variable length records. 



Write RECFM=VB as the next entry in the Operand field. This allows writing 
of variable-length blocked records. The maximum physical block size will be 
defined by the BLKSIZE parameter. 



Write BFTEK = S as the next entry in the Operand field. This allows the 
logging device to use simple buffering techniques. 



To define the device upon which the data is to be logged, a DEVD parameter 
is needed. The various options for this device are described in the referred 
OS AM document. For illustration, the specification of a magnetic tape 
device with a recording density of 556 bits/inch, odd parity, BCDIC to 
EBCDIC translation, is written as: DEVD = TA, DEN = 1, TRTCH = T. 



The logging device DCB section is completed, 
terminal table. 



The next section will define the 




SECTION D. TERMINAL TABLE 



pp. 6,8 



The sections needed to define the Data Sets are finished. The next sections I 

will define Control Information needed for QTAM. I 



:i 



Write "Section D. Terminal Table" in the margin at the top of the next 
coding sheet. This will identify the macro statements for Section D. 



X 



' The first Control Information Section that will be specified is that of the 
I Terminal Table. The series of statements needed to define the size of the 
I table, each terminal device in the system, each distribution list of termi- 
nals, and each processing message queue is described here. (Other 
I information about the particular terminal devices is specified at System 
Generation time.) 



n 



I Ge 



£ 



_i 



Write TERMTBL in the Operation field of the first macro statement. 



EXAMPLE TERMTBL 



Nc 



Operation 



TERMTBL 



Operand 



The next type of statement that may be specified, following the TERMTBL | 

I statement, is one that will identify and give the size of optional user fields within l 

I each TERM terminal entry. There must be one of these statements for each type ' 

optional field. The optional fields defined might be used for such things as to | 

limit the number of consecutive polls for a terminal, to supply QTAM with an i 
I alternate destination for a terminal, or any other user-desired information that 

I is needed on a per-terminal basis. If an INTERCEPT macro is specified in the | 

I LPS section, a two-byte optional field named INTERCPT must be specified. I 



D2jp.ll 



10 



n 




In the next macro statement for this section, enter into the Name field the 
symbolic name (maximum of 8 characters) of the field to be defined. 

Ex: LIMIT 



EXAMPLE OPTION 



1 Name 


Operation 


Operand 1 


[limit 


OPTION 


FL3 1 



Write OPTION in the Operation field of the macro statement. 



In the Operand field of this macro statement define with assembly language 
notation the length and type of optional field whose contents will be 
specified by the TERM macro statement. 

Ex: FL3 Ex: CL8 Ex: XLS 



i 

I The next type of statement (TERM statement) to be specified is the type 
I that defines terminal or group code entries. (A group code allows a 
group of terminals on a given line to simultaneously receive a message.) 
I One of these statements is needed for each terminal and group code in 
I the system. 



17, 



1 



■ Although the following discussion Is written per statement, a TERM statement ■ 

I should be written concurrently for each terminal (or group code) in the system. I 



L 



For each TERM statement to be defined, write in the Name field the symbolic 
name for each terminal or group code to be defined. The symbolic names 
assigned will be referred to as "Terminal Table entry names" and will be stated 
in message headers to identify message source and destination(s). Each symbolic 
name may be of a different length, up to a maximum length of 8 characters, 
provided that they are delineated by blank character(s) when stated in the message 
header. (A field equivalent to the maximum name specified will be reserved for 
each TERM statement entry.) If they are not delineated by blank characters in 
the message header, each name must be of the same length, and that length must 
be specified In the functional macro statements that reference them. 

Ex: NYC 



EXAMPLE TERM 



Name 



NYC 



Operation 



TERM 



Operand 



L,DCBLINE,1,6202620E,(1) 



Write TERM In the Operation field of the macro statement. 



I Information to be entered In the Operand field of the Term statement I 

depends on the terminal type and desired method of operation. Those currently 
supported will be classified here as: 

Type 1. IBM 1050 - Polled Terminals 
IBM 1060- Polled Terminals 
AT&T 83B3 - Polled Terminals 
WU 115A- Polled Terminals 
IBM 1050- Dialing 
Common Carrier TWX 



Type 2. 
Type 3. 
Type 4. 



IBM 1030 







12 
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No 




Yes 



Write L as the first entry in the Operand field of the macro statement. 
This causes the outgoing messages to be queued by line. 



Write T as the first entry in the Operand field of the macro statement. 
This causes the outgoing messages to be queued by terminal. 



Next write in the Operand field a comma followed by the symbolic name of 
the DCB defining the line group to which this terminal is attached. 
Ex: ,DCBGRUP1 



r 



I 



Next write in the Operand field a comma followed by the symbolic name of 
the line group to which this terminal is attached. 
Ex: ,DCBGRUP1 



I The relative line number (rin) of a communication line within a line group is 
I determined by the order in which the lines will be listed in the Data . 

Definition (DD) Statement. If, for example, a line is specified first, its | 

rIn is one. 



Next write in the Operand field a comma followed by a 1 . 

Ex: ,1 



|_rln 



1 



Write in the Operand filed a comma followed by the rIn for the line to which 
the terminal being described is attached. 

Ex: ,1 



Next write in the Operand field a comma followed by: 

1 . Number of dial digits, specified in EBCDIC hexadecimal notation, 

2. Actual dial digits for this terminal, in EBCDIC hexadecimal notation. 

3. Two addressing characters, specified as a hexadecimal number using 
1050 code structure. 

Ex: ,F7F3F8F3F6F9F3F06202 



D5 pJ5 




Next- wrife in the Operand field a comma followed by fhe two-character 
addressing and polling codes respectively for the terminal whose TERM 
statement is currently being described. The code must be specified in the 
terminal's Code Structure as a hexadecimal number (see IBM 2702 Trans- 
mission Control , A22-6846). If this TERM statement is for a group code, 
only the addressing code is specified. 

Ex: ,6202620E 



<^<- 




Next write in the Operand field a comma followed by: 

1. Number of dial digits, specified in EBCDIC hexadecimal notation. 

2. Actual dial digits for this terminal, in EBCDIC hexadecimal notation, 

3. Number of identification digits, in EBCDIC hexadecimal notation. 

4. Actual identification digits for this terminal, in hexadecimal Eight- 
Bit Data Interchange Code. 

Ex: F4F3F8F3F6F4F8F1F2F3 



The terminals presently being described must then be of Type 4 

T 



J 



Next write in the Operation field a two-character addressing code for the 
present terminal specified as a hexadecimal number using 1030 Code Structure 
(see IBM 2702 Transmission Control , A22-6846). QT AM will develop 
the polling characters needed. 

Ex: 6207 

1 



-►t-* 
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Write in the Operand fields of the TERM statements the actual data to be Inserted 
Into the optional fields that were defined by the OPTION macros. The data 
must be of the type and size that was specified. The data to be written in the 
optional fields must be specified In the same order as the OPTION macros 
that define the fields. The data for all fields must be written within parentheses, 
preceded by a comma, with the fields separated from each other by commas. 
Ex: ,(1) Ex: ,(l,OPR) 




' Since the application Is not strictly message switching, some of the messages 
I need special processing. To do this, the messages are sent to a process queue I 
I where the user's processing programs can access them by means of GET/PUT | 
I macro Instructions. The statements needed to define these process queues are j 
• called PROCESS macro statements. Messages that would need special i 

I processing could be Inquiry, Data Collection, Control Messages, etc. i 



EXAMPLE PROCESS 



Name 



INQ 



Operation 



PROCESS 



Operand 



'-<- 



<-^ 



In the next macro statements enter into the Nome field the symbolic name 
assigned to each Process queue. These names are subject to the same 
restrictions as terminal table entry names specified in the TERM statement. 

Ex: INQ 



Write PROCESS in every Operation field that contains a Process queue terminal 
table entry name. 



3 



I Messages destined for process queues may be routed directly to a process program,! 
I bypassing the normal queuing on a DASD (or in core storage). If messages 

lore routed directly, their segments are not collected until the entire message is I 

I received. GET macro instruction may then obtain interspersed segments of other I 
I messages betv/een segments of a multisegment message. If direct routing is 

1 specified, the messages are not written on the DASD and the RETRIEVE macro | 

may not be used. I 




Write EXPEDITE in the Operand field of the process statements that define 
"direct routing" queues. 

Ex: EXPEDITE 



A destination code can be a "terminal table entry name" that represents a list I 
of terminals. Each terminal on the list vv'ill represent a destination for the | 

message. I 




T6 



17 




The next type of statement (LIST) to be specified define distribution lists 



:i 



_j 



In the next macro statements, enter into the Name fields the symbolic names 
assigned to the distribution lists. These names are subject to the same 
restrictions as the terminal table entry names specified by the TERM statement. 

Ex: PBW 



EXAMPLE LIST 



Name 



PBW 



Operation 



LIST 



Operand 



(PHI, BOS, WAS) 



Write LIST in every Operation field specifying a distribution list. 



I 



The entries to be made in the Operand fields of the LIST statements are the 
names (of TERM or PROCESS statements) that are to be included in the 
distribution lists. The names must be separated by commas, and the group 
enclosed by parentheses. 

Ex: (PHI, BOS, WAS) 



Go back and fill in the Operand field of the TERMTBL statement with the name 
of the last entry in the Terminal Table, followed by a comma and the decimal 
number of bytes used by the maximum-length Terminal Table entry name. 

Ex: INQ,3 



EXAMPLE TERMTBL 



Name 



Operation 



TERMTBL 



Operand 



INQ,3 



We are now able to finish specification of the ACLOC parameters that were not 
written in the Communication Line Group DCB's in Section A. The numbers to 
be written in the blank spaces reserved will define the "Device Address" field 
of each terminal relative to the first character of its Terminal Table Entry. 

To calculate this decimal number n, use the formula n = 9+x+y, where 

X = the maximum number of characters used for a TERM statement Terminal Table 
entry name and y = the number of characters used for optional fields in each 
TERM statement. 

Ex: ACLOC=14 



EXAMPLE DCB 



Name 


Operation 


Operand 


DCBGRUPl 


DCB 


DDNAME^DDGROUP, DSORG=CX, 






MACRF=(G,P),CPOLL= 






(POLLINE1, POLLINE2), INTVL=5, 






BUFRQ=3,ACLOC=14, 






CLPS=LPS1 



9. 



20 
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SECTION E. POLLING LIST 



|lT]p.l8 

J 



Write " Section E. Polling List" in the margin at the top of the next blank coding 
sheet. This will identify the macro statements for Section E. 



1 



I Each line in the line group must have a polling list associated with it. Lines that i 

I are for output only, or any non-polled lines, may share a common polling list I 

with no terminal entries in it. The terminals on each line must be listed in the I 

I order In which they are to be polled. A given terminal may be listed more than i 

I once within a list. Each terminal on the list will be polled to exhaustion unless ' 

I a POLLIMIT macro instruction Is specified In the LPS. The polling list | 

I is specified with a POLL statement. I 



a 



Write symbolic names (up to 8 characters) for each polling list to be specified 
in the Name fields of the macro statements for this section. The names will be 
specified in the CPOLL parameter of the line group DCB. Each of these will be 
a POLL statement — one for each line. 

Ex: POLLINE2 



EXAMPLE POLL 



Name 



POLLINE2 



Operation 



POLL 



Operand 



(NYC, PHI, NYC, WAS) 



Write POLL In the Operation field of each of these macro statements. 



1 



Write in the Operand field for each POLL statement a list of the polled terminals 
on its associated communication line. (There will be none for the non-polled 
lines.) This polling list must contain the terminal table entry names in the order 
In which they are to be polled for each line. These terminal table entry names 
must be those used in the Name fields of the TERM macro instructions. The 
entry names must be separated by commas, and the group enclosed by parentheses. 
A given entry name may be listed more than once in a given POLL macro 
instruction. 

Ex: (NYC, PHI, NYC, WAS) 



L 

I The polling list section has now been completely specified. Go to the next | 

I section which defines the buffers, I 




20 



21 



SECTION F. BUFFERS 



Flip. 20 



Wrfte "Section F. Buffers" fn the margin at the top of the next blank coding sheet 
This will identify the macro statement for Section F. 



____! 

i A statement is needed to define the size of a buffer pool and to define whether ' 

main storage or direct access device queuing is to be used. The statement used | 

I to specify this is the BUFFER statement. I 

n 



Write BUFFER in the Operation field of the macro statement for this section. 



EXAMPLE BUFFER 



BUFFER 




Operation 



Operand 



DCBFILE, 10,95 



The first entry in the Operand field of the BUFFER statement must identify the 
symbolic name given to the direct access device DCB statement. 

Ex: DCBFILE 



Place a comma next in the operand field of the macro statement. 



[Jp. 
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The next enfty to be made in the Operand field is the decimal number of buffers 
to be reserved for QTAM. An order of magnitude estimate for the number of 
buffers required will be the product of the number of lines in each line group 
times the BUFRQ parameters of the line groups. 

If main storage queuing is to be used, the amount of core storage needed must 
be provided for in the buffer number specification. (Maximum number of buffers 
= 32,768). The specified number must be followed by a comma. 

Ex: 10, 



The next entry to be made in the Operand field is the number of bytes in each 
buffer. All buffers in the buffer pool will be of this length. The minimum-size 
buffer is equal to the message header prefix (32 bytes) plus the maximum size of 
the message header. The maximum size that may be specified for the buffer 
length is 278 bytes. 

Ex: 95 



T 



~l 



I The buffers section is completed. 

___i_ 

I Before leaving the system definition sections of the Message Control Task | 

I specification, there Is one more related item-definition of a subtask to i 

I operate within the Message Control Task — if such an operation is desired I 
I (refer to Introduction). 




Write in the Name field of the next available macro statement the name 
to be given to the subtask. 

Ex: SUBTl 



EXAMPLE DFNSUBT 



Name 



SUBTl 



Operation 



DFNSUBT 



Operand 



STRTSUB1,3 



Write DFNSUBT in the Operation field, 



1 



Write in the Operand field the symbolic name of the entry point in the subtask. 

Ex: STRTSUBl 



Next write in the Operand field a comma followed by a decimal number up to 254 
to designate the priority to be assigned to the subtask. 

Ex: ,3 




Yes 



$ 
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25 



SECTION G. RECEIVE SEGMENT 





1 



Data Sets and Control Information Sections have now been completely specified. | 
I The next area to be considered is that of the Line Procedure Specification (LPS) 

I An LPS defines the message-handling and header analysis functions for messages 
I sent and received on communication lines. Each group of lines that have the same 
I terminal controls and transmit the same message formats will need an LPS. 

The next chart sections will define statements that when finally assembled will | 

make up an LPS. When more than one LPS is needed to make up the Message i 

I Control Task, directions will be given to repeat these sections until each LPS I 

I has the set of macro statements needed to perform Its desired functions. I 

I * ; ; ; ; 1 

I If a subtask of the Message Control Task was defined In the previous section, it i 

I Is here pointed out that activation of such a subtask can be specified at any I 

I point within any of the LPS sections about to be specified. This is accomplished I 

I by writing on ACTSUBT macro statement, with the name of the subtask as its ' 

Operand parameter, at the point that activation is desired. It Is Important to I 

note that the subtask will be activated each time the sequence of macros in 

I which the ACTSUBT macro Is embedded Is referenced. To operate In other than | 

I this manner, the ACTSUBT macro may be Included In the Data Set Initial- i 

I Ization section described later in this book. ' 

' Deactivation of a subtask is accomplished within the subtask Itself by use of an i 
[ENDSUBT macro statement. _j 



'J 



The macros needed to specify an LPS will now be defined. 



i 



Write "Section G. Receive Segment" in the margin at the top of the next blank 
coding sheet. This will identify the macro statements for Section G. 



X 



I Each LPS requires as Its first statement a LPSTART macro. The LPSTART macro 
I identifies the beginning of the LPS and reserves space In the first buffer of the i 

'input message for insertion of timestamp, datestamp, and output sequence number I 
I fields. I 



J. 



Write LPSTART in the Operation field of the first macro statement for this section. 
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EXAMPLE LPSTART 



Name 



LPSl 



Opergtign 



LPSTART 



Operand 



Write in the Name field a symbolic name of 8 or fewer characters to identify this 
LPS. This name is used for the CLPS parameter of the associated Communication 
Line Group DCB (Section A). 

Ex: LPSl 



i 



Write RCVSEG in the Operation field of the next macro statement for this section 
to identify the succeeding macros of this section as those concerned with both 
header and text portions of the message received. (This type of macro statement 
is known as a delimiter macro and is not to be confused with the delimiter 
character which is a blank.) 



EXAMPLE RCVSEG 



Name 



Operation 



RCVSEG 



Operand 



Specify code translation of the incoming message by writing TRANS in the 
Operation field of the next macro statement. Normally only one receive code 
translation table is permitted per LPS/Line Group. 



EXAMPLE TRANS 



Name 



Operation 



TRANS 



Operand 



RCVE1050 



Write the symbolic name of the particular code translation table needed for 
the incoming messages in the Operand field of the macro statement. 

Ex: RCVE1050 



i__^ , ^ 

It is possible to log entire messages at this stage of header analysis. Messages | 

I logged on an external I/O device at this point will not contain header additions l 
I such as timestamp or datestamp. It should be noted that this logging is in addition I 
I to the queuing of messages on the DASD. I 



Code Translatfon Tab 


es Provided by QTAM 


Name 


Code 


RCVE1050 


1050 to EBCDIC 


RCVE1030 


1030 to EBCDIC 


RCVETl 


TTY to EBCDIC 


RCVET2 


TWX to EBCDIC 


RCVF1050 


1050 to monocase EBCDIC 




Write the symbolic name of the DCB associated with the desired external logging 
device in the Operand field of the macro statement. 

Ex: LOGFILE 



r 



I A macro is provided that can check for a maximum length on input messages and I 
I also determine if all characters in an input buffer are the same. Detection of i 
I either of these conditions v^'ould result in an error bit being set in the error I 

I halfword (BREAKOFF ERROR) and reception of the message terminated. I 



G4j p. 29 



28 




29 



Write BREAKOFF in the Operation field of the next available macro statement 
in this section. 



EXAMPLE BREAKOFF 






1 Name 


Operation 


Operand 1 


L__ 


BREAKOFF 


1500 1 



In the Operand field write a decimal number <32000 to specify the maximur 
length of input messages to be allowed. 

Ex: 1500 



->^' 



All the macro statements that affect both the header and text portions of incoming 
messages have been accounted for. Proceed to the next section that is concerned 
only with the incoming message headers. 




SECTION H. RECEIVE HEADER 




Write "Section H. Receive Header" in the margin at the top of the next blank 
coding sheet. This will identify the macro statements for Section H. 



Write the delimiter macro RCVHDR in the Operation field of the first macro 
statement for this Section to identify the succeeding macros of this section as 
those concerned only with incoming message headers. 



R"h 



EXAMPLE RCVHDR 




1 Nome 


Operation 


Operand | 


l__ 


RCVHDR 


1 



This section of the LPS will perform the desired header analysis/synthesis of I 

Incoming message headers. To do this, it is necessary to start at the beginning of | 



the message header and proceed through it (left to right) by specifying the i 

appropriate functional macro instructions in the same order in which they apply . 

to the header. As each macro that operates on a particular field is executed, I 

the LPS will advance to the beginning of the next field of the header before the | 

next macro will be executed. The beginning of the next field will be the first i 

nonblank character after the end of the field being operated on. It should be ' 
noted that all blank characters will automatically be skipped between the fields. 



T_ 



pt is important that the LPS be kept aligned with the actual message header by I 

I proper delineation of the header fields. This is done by specifying field lengths | 

I within the macro statements and by skipping over nonblank fields not involved | 

I in header analysis with the SKIP macro. j 



X 



[At this point the LPS program is automatically aligned with the first character of | 
Ithe received message (not necessarily the first meaningful character of the header) J 
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No 




Write SKIP In the Operation field of the next macro statement 



EXAMPLE SKIP 



Name 



Operation 



SKIP 



Operand 



I Skipping can be accomplished by either skipping a fixed number of nonblank 

I character positions or by having a certain character configuration specifying the | 

I end of a field to be skipped. i 



Yes 



Write in the Operand field of the SKIP statement the actual number of 
nonblank characters to be skipped. This number cannot be greater than the 
number of character positions remaining in the buffer. 

Ex: 8 




No 



Write in the Operand field of the SKIP statement a comma followed by C'chars', 
where chars represents a certain character configuration that denotes the end of 
the field(s) to be skipped. The character configuration must not exceed 8 
characters. Ex: ,C'$' 



EXAMPLE SKIP 



Name 



• Operation 
SKIP 



,C'$' 



Operand 



I The first character of the header field of Interest to header analysis should now 
I be aligned. 



J 
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I It is possible to log only Input message headers on an external I/O device. | 

I Further definition of at just what stage of header analysis the header will be logged i 

I depends on the position of the LOGSEG macro withing the RCVHDR section. I 

(This logging is in addition to queuing of the complete messages.) J 




Write LOGSEG in the Operation field of the next available macro statement to 
specify external logging of incoming message headers. 



EXAMPLE LOGSEG 






1 Name 


Operation 


Operand | 


1 


LOGSEG 


LOGF1LE2 1 



Write the symbolic name of the DCB associated with the desired external logging 
device in the Operand field. 

Ex: LOGFILE2 
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I If messages received from lines using the same LPS require different handling I 

procedures, a macro (MSGTYPE) can be used to sectionalize an LPS into separate I 
I procedures for each type message. The LPS can in effect be broken into smaller 
I LPS sections for sequences of macro instructions that will apply to only certain | 
I messages. Only the macros appropriate to each type of message will then be 
' executed. In general, a MSGTYPE macro will be needed to delineate each such 
sequence of macros. 




EXAMPLE MSGTYPE 



Nc 



Operation 



MSGTYPE 



Operand 



I A special character in the header field may be used to identify all incoming | 

I messages that will use the next sequence of macros. If no special character is 
I present, all such messages will be handled by the next sequence of macros. A 
I MSGTYPE macro, with no special character, must be specified to identify the 
sequence of macros to handle these messages. 




No 



Write this special character in the Operand field 

Ex: C'P' 



I The Operand field will remain blank. This MSGTYPE macro statement will I 

I normally be the last MSGTYPE macro in this section, since it must handle all | 

[remaining messages that did not have a defined type. I 



->r*- 



EXAMPLE MSGTYPE 



Name 



Operation 



MSGTYPE 



Operand 



C'P' 



iL_. 



I All macro statements listed from this point In the LPS to the next MSGTYPE or I 

I delimiter macro w ill app l y only to the type message just de s ignated . | 
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ITo operate In the conversational mode means that a terminal sending a message ' 
ill retain control of the communication line until the reply Is received. I 




34 



35 



^ 



p. 34 




Write MODE in fhe Operation field of the next available macro statement. 



EXAMPLE MODE 



Name Operation 



MODE CONVERSE 



Operand 



Write CONVERSE in the Operand field. 



i 



I For very long messages in a message-switching application, it may be desirable to | 
I initiate sending of a message before it is completely received. I 




Write MODE in the Operation field of the next available macro statement. 



I 



Write INITIATE in the Operand field. 



EXAMPLE MODE 



Nc 



Operation 



MODE 



INITIATE 



Operand 



I It is possible to have aj_[ messages that use this part of the LPS operated on at this ' 
I point (before header analysis) by a user-provided routine/ the function of which is 

up to the user. Certain precautions must be taken when including such routines. i 
I For further discussion of the possibilities and consequences of doing this, the reader] 
I is referred to IBM Operating System/360: Telecommunications. (C28-6553). I 




The MODE macro provides 1-he exit to the user routine and the return address 
I General Register 14. General Registers 2,3,9,10,12,15 may be used in the 
I user routine and General Register 1 must be used as a base register. 



J 



U 
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Write DATESTMP in the Operation field of the next available macro statement. 
No parameter is needed in the Operand field to specify the length of the field, 
since it is a fixed number (7); 7 spaces will be reserved for the insertion of 
datestamp by the LPSTART macro. The datestamp insertion will be of the 
following format: bYY. DDD, where b = blank, YY = year, DDD = day of year. 




It is not possible to check the input sequence | 
I number of this point unless a SOURCE macro has 1 
I been previously specified. This implies that a I 
I "source" field appears in the message header. I 



fln]p.3& 




Write in the Operand field a decimal number for the length of the input sequence 
number field as found in the message header (4 max). 

Ex: 3 



The SEQIN field con then be of variable length. No parameter is needed in 
the Operand field of the SEQIN statement. The LPS will advance in the 
message header past the last character of the SEQIN field. 



Hnjp.37 
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Yes 
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EXAMPLE ROUTE 






1 Name 


Operation 


Operand 1 




ROUTE 


5 



Yes 



Are blank characters used 
to delineate the message destinations 
Jield(s) from each other and the next 
header field ? 



No 



In the Operand field, write in decimal the number of characters that make up 
each message destination code. They must all be the same length (max of 8 
characters) and must all be terminal table entry names. 

Ex: 3 



I 



iH20 p. 47 

V 
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No 




EXAMPLE MODE 




1 Name 


Operation 


Operand | 


L_^ 


MODE 


ROUTINE, C'l' 1 



Wrlfe MODE In the Operation field of the next available macro statement. 



p. 48 



In the Operand field write the symbolic name of the user-provided routine to be 
®"^®''®^- Ex: ROUTINE! 



1 



I The MODE macro provides the exit to the user routine and the return address In ' 
I General Register 14. General Registers 2,3,9,10,12,15 may be used In the user | 
[routine and General Register 1 must be used as a base register. I 



I The MODE macro may operate on this MSGTYPE section, either conditionally by 

specifying a special message Identification character to Identify when the user- 

I provided function Is to be entered, or unconditionally by not specifying a second 



[parameter so that the routine will be entered for each message 
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I In the Operand field write a comma followed by C'char', where char is the 
j special character that identifies the message as one that is to be operated on 
by the user-provided function. Ex: ,C' !' 



^__ 

I The LPS will now be ready for the next field in the header following the special I 
I character. 




I There are two ways to specify priorities within messages: I 

11. A special character in the header of priority messages to indicate that the I 

I very next character following it contains the actual message priority. . 

I 2. Only the actual message priority in the message header. In this cjse, a | 

I message priority must be given to every message using this part of the LPS. I 



r 



Write MODE in the Operation field of the next available macro statement. 



Write PRIORITY in the Operand field. 



EXAMPLE MODE 



Nc 



Operation 
MODE 



Operand 



PRIORITY 




Next, in the Operand field write a comma followed by C'char', where char is 
the special character that is to precede the message priority character in the 
message header. Ex: ,C'*' 



i The LPS will now advance in the message header to the last character of the field 
I just processed. 



H22|p.48 
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n 



' A special characfer field may be specified in the message header to indicate 

I conversational mode of operation, or the desire to start sending a message 

I before it is completely received. I 




Yes 




I All the message header fields of concern while receiving a message should have | 
I been taken care of at this point. Try one more pass through the logic flow. I 



lH22j p. 48 
CONVERSATIONAL MODE 



Write Mode in the operation field of the next available macro statement 




NITIALIZATION MODE 



Write MODE in the Operation field of the next available macro statement. 



EXAMPLE MODE 



Name 



Operation 



MODE 



Operand 



CONVERSE, C'n' 



In the Operand field write CONVERSE. 



In the Operand field write INITIATE. 



EXAMPLE MODE 



Name 



Operation 



MODE 



Operand 



INITIATE, C'?' 



Next, in the Operand field write a comma followed by C'char', where char 
is the character that is to specify that conversational mode of operation is 
wanted with this message. 

Ex: ,C'n' 



Next, in the Operand field write a comma followed by C'char', where char 
is the character that is to identify this message as one that can start sending 
before being completely received. 

Ex: ,C'?' 




44 



45 




JHT8|pp.37,38,46 



Write in the Operand field, in decimal, the number of characters n (2 < n < 12 
depending on the time increment desired) reserved for the timestamp field. 
The time of day will be given in the form bHH.MM.SS.th, where b = blank, 
HH = hours, MM = minutes, SS = seconds, t - tenths of a second, and h = 
hundredths of a second. When fev/er than twelve spaces are reserved, the time 
will be truncated from the right. 

Ex: 9 



T 



I The LPS will now advance in the message header past the last character of the I 
field Just processed. 



I 



H22 p.48 
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^ 



Write SOURCE in the Operation field of the next available macro statement, 



EXAMPLE SOURCE 



Name 



Operation 



SOURCE 




Yes 



Operand 



Write in the Operand field a decimal number for the length of the source field 
in the message header (max 8). Ex: 3 




I The LPS will advance in the message header past the last character of the 1 
I source field. 1 
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EXAMPLE EOA 



Operation 



EOA 



Operand 



C'% 



Write EOA in the Operation field of the next available macro statement. 




i 



In the Operand field, write C'*^' where ^ represents in EBCDIC code the trans- 
lated character that will be used in the message header to designate the end of al 
destination fields. Ex: C'%' 



A 



I The LPS will now advance in the message header past the last character of the end I 
[of destination field (EOA). I 



A fixed destination for all messages handled by this LPS section or fixed 
destinations for messages from each source terminal can be specified by the 
use of a single DIRECT macro. To do this, write DIRECT in the Operation 
field of the next available macro statement. 




r^^ 



In the Operand field write = C 'dest', where dest is the symbolic name of 
the destination. This destination must be a terminal table entry name. 
Note: The DIRECT macro instruction may be issued only once per LPS 
MSGTYPE section. Ex: = C'CHI' 



-^«< 



EXAMPLE DIRECT 



Name 



Operation 



DIRECT 



Operand 



= C'CHI' 



If the terminals are non-polled this can be done only if a source 
macro has been previously specified In this LPS, 



£ 



Write in the Operand the symbolic name of the optional 
field in the terminal table that contains the desired 
destination for messages from each terminal, (Refer to 
section D.) Ex: DEST 



[H22|pp.38,40,41, 

42,44,45,46 
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Write the symbolic name of the DCB associated with the desired external logging 
device in the Operand field. 

Ex: LOGFILE2 



No 



[h24]p.49 
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Write RCVSEG In the Operation field of the next available macro statement. 
(This makes the following LOGSEG macro apply to both header and text.) 



EXAMPLE RCVSEG 



Name 



Operation 



RCVSEG 



Operand 



Write LOGSEG in the Operation field of the next available macro statement. 



EXAMPLE LOGSEG 



Name 



Operation 



LOGSEG 



Operand 



LOGFILE2 



Write the symbolic name of the DCB associated v^ith the desired external logging 
device in the Operand field. 

Ex: LOGFILE2 




EXAMPLE SKIP 



Name 



Operation 



SKIP 



C'#' 



Operand 



I A field can be skipped by either specifying a given number of nonbionk 



I characters to be skipped or by specifying a particular character configuration that I 
I will Indicate the end of the skipped field. i 




Write C'chars' in the Operand field of the SKIP statement, where chars represents 
the particular character. configuration in the internal system code. 



Write in the Operand field of the SKIP statement the actual number of nonblank 
characters to be skipped. The number cannot be greater than the number of 
character positions remaining in the buffer, past the present position of the LPS. 

Ex: 10 
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EXAMPLE SKIP 
I Name 



Operation 
SKIP 



10 



Operand 



50 
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SECTION J. END RECEIVE 



Jl pp. 44, 49,51 



Write "Section J. End Receive" in the margin at the top of the next blank coding 
sheet. This will identify the macro statements for Section J. 



EXAMPLE ENDRCVE 



Name 



Operation 



ENDRCVE 



Operand 



To identify the following section of the LPS as macro instructions concerned only 
with functions to be performed after the entire message has been received, write 
the delimiter macro statement ENDRCVE in the Operation field of the first 
macro statement for this section. 
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No 



Write EOBLC in fhe Operation field of fhe next available macro statement. 




Write EOB in the Operation field of the next available macro statement. 



> ♦ < 



-X' 



EXAMPLE EOBLC 



Name 



Operation 



EOBLC 



Operand 



EXAMPLE EOB 



Name 



Operation 



EOB 



Operand 



(To provide for specification of error procedures, a halfword error mask is maintained! 
I for each communication line. This mask can be interrogated by macro statements, | 
land the desired error procedure initiated upon finding a given error condition, I 

J_ 

I QTAM provides fixed error procedures for sending an error message, canceling I 
I an erroneous message, and rerouting of messages. With each error orocedure | 

I specified, an error mask representing the error condition that the error procedure I 
I is to act on, must be specified in hexadecimal notation. Chart 1 describes the I 
I er rors pro vide d for when receiving. j 



i: 



An example of how to specify an error mask: 

The error halfword s pecifying a transmission error looks like this: 

[o |o |o| o|o| o|o|o|Ho| o|o| o|o |oTo" 



n 



I ^ 8 

I Its corresponding error mask in hexadecimal will be written as X'0080' 



Charl- 1: Halfword Error Mask 
Hexadecimal Error Mask Positions 

Hex 2 Hex 3 



Bit Positions 



Hex 1 Hex 2 Hex 3 Hex 4 

1 23456789 1011 1213141516 
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A 1-bit in any position indicates the presence of the error 
condition associated with that position. 
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Write ERRMSG in the Operation field of the next available macro statement in 
this section. 



EXAMPLE ERRMSG 



Name 


Operation 


Operand 




ERRMSG 


X'0080' , ERRDEST, =C' Ebbbbbbbbb. MESS 






AGEbCONTAINSbAbTRANSMISSIONb 






ERROR 



In the Operand field write the error mask of the error condition for which this 
message is to be sent, specified as X'mask' where mask is a four-digit hexa- 
decimal number. Ex: X'OOBO' 

I 

J5|p.55 
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If the message causing the error came from a non-polled terminal, a ' 

SOURCE macro must have been previously specified in the LPS and | 

la source field must be in the message header. I 




To provide for this, an optional field can be specified for the Terminal 
I Table entries that would contain the desired error message destinction. The . 
'Terminal Table entry whose optional field is used would be the one defining I 

the terminal that had sent the message that caused the error condition. 
I (See Option statement. Section D.) Note: If the terminal that sent the i 
I message causing the error is a non-polled terminal, a SOURCE macro must ' 
I have been previously specified in the LPS. 



ra 
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Next, in the Operand field write a comma followed by the fixed destination 
specified as = C'dest', where dest represents the symbolic name of the 
destination Terminal Table entry name. 

Ex: =C'PHr 



Next, in the Operand field write a comma followed by the name of the 
optional field in the Terminal Table that contains the desired 
destination. 

Ex: ERRDEST 



>H-^ 



I The contents of the error message text must now be specified. This error message 
I text can be stated directly in the Operand field of the ERRMSG statement or it can 
I be prestored in a symbolic location and referenced by the ERRMSG statement, 
I Before writing this text, however, the following items must be known: 
' 1 . The first part of the error message text must be a header compatible with the 

LPS for sending (same as other output headers). 
I 2. The entire error message header, plus text, is not to exceed the length of a 
I buffer. 

I 3. A period as the first character of the error message text will be replaced by the 
I header of the message whose transmission caused the error. This additional 

header must be considered in (2) above. 



Yes 



Is the error message prestored 



No 



^ 


\^ in a symbolic location V ^^ 

1 \f 


Next, in the Operand field write a comma followed by the symbolic name of the 
location in core storage that contains the desired error message. This location 
and its contents must be defined elsewhere. 

Ex: ERRTEXT 




Next, in the Operand field write a comma followed by the header plus text, 
specified as = C'errmsg', where errmsg represents the actual header and 
message text. 

Ex: ,=C'Ebbbbbbbb.MESSAGEbCONTAINSbAbTRANSMISSIONbERROR 




. J 


►♦-« 
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In the Operand field write the error mask for the desired error condition specified 
as X'mask', where mask represents the four-digit hexadecimal number. 

Ex: X'8600' 



Yes 




Next, in the Operand field write a comma followed by the Terminal Table entry 
name of the rerouted destination, specified as =C'tername' where tername is the 
symbolic name of the destination. 

Ex: =C'NYC' 



Another choice of reroute destinations is to have an alternate destination 
specified in an optional field of the message source entry in the Terminal 
Table (see Terminal Table Specification). To use this alternate destination, 
next in the Operand field write a comma followed by the symbolic name of 
the optional field that is to contain the alternate destination for each terminal 
entry. Ex: RERTE 
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When a message is canceled, all references l-o it are destroyed, 

T 



n 



Write CANCELM in the Operation field of the next available macro statement in 
this section. 



EXAMPLE CANCELM 



Name 



Operation 



CANCELM X'0020' 



Operand 



In the Operand field write the error mask for the desired error conditions, 
specified as X'mask', where mask represents the four-digit hexadecimal number. 

Ex: X'0020' 



I Only one CANCELM statement is needed since all error types requiring message | 
illation can be specified in the same error mask. I 




Write POLLIMIT in the Operation field of the next available macro statement. 



EXAMPLE POLLIMIT 



Name 



Operation 



POLLIMIT 



Yes 




Operand 



LIMIT 



In the Operand field write ^FLl'n', where n is the decimal number specifying 
the maximum number of consecutive polls for each terminal . 

Ex: =FLT2' 



EXAMPLE POLLIMIT 



In the Operand field write in the symbolic name of an optional field in the 
terminal table that contains the poll limit desired for each terminal (see 
Section D). Ex: LIMIT 



->^-^ 



Name 



Operation 



Operand 



POLLIMIT 



=FLT2' 




-^M 



EXAMPLE POSTRCVE 



Name 



Operation 



POSTRCVE 



Operand 



Write POSTRCVE in the Operation field of the next available macro 
statement. This identifies the end of the ENDRCVE section. The receive 
part of the LPS is now completely specified. 
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SECTION K. SEND HEADER 




Write "SecHon K. Send Header" In the margin at the tape of the next blank coding 
sheet. This will Identify the macro statements for Section K. 



I 



To identify the first section of the send LPS as that pertaining to only outgoing 
message headers, write SENDHDR In the Operand field of the first macro 
statement for this section. This is a delimiter macro. 



EXAMPLE SENDHDR 



Nc 



Operation 



SENDHDR 



Operand 



It is possible to log only output message headers on an external I/O device. 

I Further definition of the state of development at which the header will be i 

I logged depends on where In the SENDHDR section the LOGSEG macro is I 

given. (This logging is In addition to queuing of the complete message.) I 




62 



63 




Write the symbolic name of the DCB associated with the desired external logging 
device in the Operand field. 

Ex: LOGFILE3 



3 



I This section of the LPS will perform the desired header analysis/synthesis of ' 

I outgoing message headers. J 



"J. 



I As with the Incoming message header LPS, it is necessary to start at the 

I beginning of the output message header and proceed through It from left to 

I right by specifying the appropriate macro instructions in the some order as 

I the header fields to which they apply. 



n 



T. 



I It is important that the LPS be positioned at the proper place in the message I 

I header when each macro is executed. I 



I Each macro that inserts Information In a particular field when executed will 
{advance I the LPS the number of character spaces provided by the macro. Blank 
i-characters between fields are skipped automatically. In all other cases correct 
I positioning must be maintained by use of the SKIP macro as instructed. 



I 



The point in the message header at which the LPS and message header are aligned 
when the Send LPS Is started depends on whether the message Is from a reply 
queue (PUT), or a Switched Message. If from a reply queue, the LPS will be 
aligned with the first character of the output message as prepared by the process 
program. If it is a switched message, the LPS will be aligned with the last 
character of the last field processed by the Receive LPS. 




There must be a special character in each message header to Identify it by type 
except for one type, which may be Identified by its lack of a special character, 
(The functional macros for the latter must be the last of this section.) It is 
assumed that the very first character of a "PUT" message, and the very first 
character not processed by the received LPS In a "Switched" message, will be 
this message type character as recommended In the Message Header Preparation 
section of the Appendix. 



I 



Write MSGTYPE In the Operation field of the next available macro statement. 




EXAMPLE MSGTYPE 



Nc 



Operation 
MSGTYPE 



p. 72 



Operand 
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65 



Yes 




Write this special character in the Operand field as C'^' where # is the 
special character. Ex: C'P' 



I The operand field will remain blank in this case, indicating that all messages not I 
I having a special character will be handled by the sequence of macros immediately | 
Ifollowlng. Note: This must be the last MSGTYPE macro of the section. I 



>r^ 



EXAMPLE MSGTYPE 



Nc 



Operation 



MSGTYPE 



Operand 



C'P' 



I All macro statements listed from this point in the LPS to the next MSGTYPE macrol 
I or delimiter macro app l y only to t he typ e m essage just designated . | 



T. 



I The message type that will currently be handled is now sorted out. Therefore, | 
I the header format of this type of message is known and the required macros can I 
I now be specified to handle this message type. . 



[k5Jpp.64,69 



->i< 





A SKIP macro must be given to skip to such a position. 



*- 



J 



EXAMPLE SKIP 



Nc 



Operation 



SKIP 



Operand 



,C'$' 



Write SKIP In the Operation field of the next available macro statement. 



L 



I A skip can be made for a fixed number of nonblank character spaces or up to ' 

I a nd including a certain character configuratio n. | 



Yes 
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Write in the Operand field a comma followed by C'chars', where chars represents 
the character configuration (max 8 characters) that denotes the end of the field 
to be skipped. 

Ex: ,C'$' 




Write in the Operand field the fixed number of nonblank characters to be 
skipped. The maximum number that can be specified is the number of character 
positions remaining in the buffer past the present position of the LPS, 

Ex: 8 



-^-t-^ 



^ 
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EXAMPLE SKIP 



Nc 



Operation 



SKIP 



Operand 



~1 



The LPS should now be ready for a field of interest to header analysis. . 




Yes 



EXAMPLE SEQOUT 



Name 



Operation 



SEQOUT 



Operand 



Write SEQOUT in the Operation field of the next available macro statement. 



In the Operand write the decimal number of character spaces (n) to be used 
by the output sequence number (1<n<5), where the first character space is 
always a blank. 

Ex: 3 




X 



No 
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Yes 



^ 
^ 



An Interval timer is needed if timestamping is specified. 






Write TIMESTMP in the Operation field of the next available macro statement. 



EXAMPLE TIMESTMP 



Nc 



Operation 



TIMESTMP 



Operand 



In the Operand field write in decimal the number of characters (n) reserved for 
the timestamp field. Here n can vary from 2 to 12, depending on the time 
increment desired. (See TIMESTMP macro under Section H for the timestamp 
format.) Ex: 7 
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EXAMPLE DATESTMP 



Name 



Operation 



DATESTMP 



Operand 



Write DATESTMP in the Operation field of the next available macro statement. 



No entry is needed in the Operand field to specify the number of spaces that the 
datestamp is to occupy. However,/ spaces (n=7) must have been reserved by 
either the LPSTART macro or by the user program, as explained in Section M. 
The datestamp insertion will be of the following format! bYY.DDD, where 
b = blank, YY = year, DDD = day of year. 




I This block should not have been entered unless the foregoing premise that we are| 
lot a point in the message header where action is to be taken is false. J 





Yes 



Write MODE in the Operation field of the next available macro statement. 



EXAMPLE MODE 



Nc 



Operation 



MODE 



Operand 



USER! 



Write in the Operand field the symbolic name of the user-provided routine 
to be entered. Ex: USER! 



J. 



I The MODE macro provides the exit to the user routine and the return address in I 
I General Register 14. General Register 2,3,9,10,13,15 may be used in the user | 
I routine and General Register 1 must be used as a base register. I 



I 



The user-provided routine can operate either on every message handled by this ' 
MSGTYPE section or only on those messages containing a special identification | 
character. I 



Operation 




Operand 



USER1,C' 



Next, in the Operand field write a comma followed by C'char', where char is 
the special character that Identifies the message as one that is to be operated 
on by the user-provided routine. 

Ex: ,C'*' 
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Y 



t 

I This special character must appear as a field at the point in the message header at | 
[which the LPS is currently aligned. | 



K12 pp. 67, 68, 69, 70 

V 



-> 




Write LOGSEG in the Operation field of the next available macro statement. 



EXAMPLE LOGSEG 



Name 



Operation 



LOGSEG 



Operand 



LOGFILE4 



In the Operand field write the symbolic name of the DCB associated with the 
desired external logging device. 

Ex: LOGFILE4 




I A macro must- be provided to skip the nonblank characters to get to the next | 

I header field , J 
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SECTION L. SEND SEGMENT 



pp. 62, 72 



Write "Section L. Send Segment" In the margin at the top of the next blank 
coding sheet. This will identify the macro statements for Section L. 



To identify the following section of the LPS as macro instructions that pertain to 
both header and text portions of the output message, a delimiter macro statement 
SENDSEG Is needed. Write SENDSEG in the Operation field of the first macro 
statement for this section. 



EXAMPLE SENDSEG 



Nc 



Operation 



SENDSEG 



Operand 



Nc 




Specify external logging of outgoing messages by writing LOGSEG In the 
Operation field of the next macro statement. 



EXAMPLE LOGSEG 



Name 



Ope r ation 
LOGSEG 



Operan d 



LOGFILE4 



Write the symbolic name of the DCB associated with the desired external 
logging device in the Operand field. 

Ex: LOGF!LE4 
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Specify code translation of the outgoing message by writing TRANS in the 
Operation field of the next macro statement in this section. 



EXAMPLE TRANS 



Name 



Operation 



TRANS 



Operand 



SEND1050 



Code Translate Tables 
Provided by QTAM 


Name 


Code 


SEND1050 
SEND1030 
SENDTl 
SENDT2 


EBCDIC to 1050 
EBCDIC to 1030 
EBCDIC to TTY 
EBCDIC to TWX 



I Write the symbolic name of the Code Translation Table needed for the outgoing 
I messages in the Operand field of the workblock. 



L 



I Idle characters may be inserted after such designated characters as Carriage | 

Return, Line Feed, End of Block, or End of Message. I 




In the Operand field, the first entry will designate what characters the idle 
characters are to follow, specified as X'char', where char represents the 
hexadecimal notation of the designated character in the terminal code. 
Follow this entry with a comma. 

Ex: X'15', 



The next entry in the Operand field defines the idle character and the number of 
idle characters to be inserted, specified as nX'id', where n represents the actual 
decimal number of idle characters to be inserted after char, and id represents the 
hexadecimal notation of the idle character in the terminal code. 

Ex: 20X'17' 
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SECTION M. END SEND 



Hi 



n 



Write "Section M. End Send" in the margin at the top of the next blank coding 
sheet. This will identify the macro statements for Section M. 



To Identify the following section of the LPS as macro instructions concerned only 
with functions to be performed after the entire message has been sent, write the 
delimiter macro statement ENDSEND In the Operation field of the first macro 
statement for this section. 
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Write EOBLC in the Operation field of the next available macro statement. 




Write EOB in the Operation field of the next available macro statement. 



>t"^ 



EXAMPLE EOBLC 



Nc 



Operation 



EOBLC 



M4 p.78 



Operand 



EXAMPLE EOB 



Name 



Operation 



EOB 



Operand 



jTo provide for specification of error procedures, a halfword error mask is I 

Imaintained for each communication line. This mask can be interrogated by macro I 

jstatements, and the desired error procedure initiated upon finding the occurrence i 
[of a given error condition. 



X 



I QTAM provides fixed error procedures for sending an error message, canceling an ' 
I erroneous message, and rerouting messages. With each error procedure J 

I specified, an error mask, representing the error procedure it is to act on, must be I 
I specified In hexadecimal notation. Chart 2 describes the errors provided for 
I when sending. 



_T 



l An example of how to specify an error mask 

I The error halfword specifying a transmission error looks like this: 

I 



1 



o|o|o|o|o|o|o|o|i|o|o |o|o|o|oTo 



8 

its corresponding error mask In hexadecimal will be written as: X'0080' 



Chart 2. Halfword Error Mask 
Hexadecimal Error Mask Positions 

Hex 1 Hex 2 Hex 3 Hex 4 

Bit Positions 1 2 3 4 5 6 7 89 10111213141516 













' 


■ 


















































S 


:? 


-a 
o 




























< 


< 




























\— 


1— 


U 


(1) 


























o 


C5 


c 


> 




















" 






>N 


•X 


^o 


D 














§ 






CQ 








_Q 

-n 


u 

c 


n 














LU 










(U 


(U 


•" 


o 




















.,_ 






3 


D 




r 




















r 










0) 


















j_ 




(U 








>v 


o 


"n 














*E 


n 




u 






O 


n 


^— 


r 
























c 


c 




















F 














O) 


E 














c 




-) 






Q) 


d) 


(1) 














{J 




V) 












(U 




















r 








































— 












_ 


, 















■^ 


'~^ 



A 1-bi't in any position indicates the presence of the error 
condition associated with that position. 



No 




Write ERRMSG in the Operation field of the next available macro statement 
In this section. 



EXAMPLE ERRMSG 



Nc 



Operation 



ERRMSG 



Operand 



X'0040',=C'OPR',TMOUTERR 



In the Operand field write the error mask representation of the error condition for 
which this message is to be sent, specified as X'mask', where mask is a four- 
digit hexadecimal number. 

Ex: X'0040'. 
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Yes 



Next, in the Operand field write a comma followed by the word SOURCE. 
Note: If the terminal Involved is a non-polled terminal, a SOURCE macro 
must have been specified in the RCVHDR section of the LPS. 



Next, In the Operand field write a comma followed by the fixed destination 
specified as =C'dest', where dest represents the symbolic name of the destination 
Terminal Table entry name. 

Ex: =C'OPR' 



Next, in the Operand field write a comma followed by the name of the optional 
field in the Terminal Table that contains the desired destination. (See OPTION, 
Section D.) The optional field will be the one associated with the Terminal 
Table entry to which the message causing the error condition was to be sent. 

Ex: ERROPT 



-►f-<- 



o 



The contents of the error message text must now be specified. This error message 
text can be stated directly in the Operand field of the ERRMSG statement or it can 
be prestored in a symbolic location and referenced by the ERRMSG statement. 
Before writing this text, however, the following information must be known: 
1 . The first part of the error message text must be a header compatible with the 

LPS for sending (same as other output headers). 

The entire error message header plus text is not to exceed the length of a 

buffer segment. 

A period as the first character of the error message text will be replaced by 

the header of the message whose transmission caused the error. This 

additional header must be considered in (2) above. 



2. 



3. 



No 



Is the text of the 



Yes 



■ ■ V. riiessuye lo be wrillen us putt ol Ihis ^^" 

^v. macro statement? ^^ 


Next, in the Operand field write a comma followed by the symbolic name of the 
location in core storage that contains the desired error message. This location 
and its contents must be defined elsewhere. 

Ex: TMOUTERR 




Next, in the Operand field write a comma followed by the header plus text, 
specified as = C'errmsg', where ermsg represents the actual header and message 
text. 

Ex: , =C'Ebbbbb.TIMEbOUTbERROR' 




►•< 






Yes 
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In fhe Operand field write the error mask for the desired error condition specified 
as X'mask', where mask represents the four-digit hexadecimal number. 

Ex: X'OOIO" 



Yes 




Next, in the Operand field write a comma followed by the Terminal Table 
entry name of the rerouted destination, specified as =C'tername', where 
tername is the symbolic name of the destination. 

Ex: =C'OPR' 



Another choice of reroute destinations is to have an alternate destination specified 
in an optional field of the message destination entry in the Terminal Table (see 
Terminal Table Specification). To use this alternate destination, next in the 
Operand field write a comma followed by the symbolic name of the optional field 
that is to contain the alternate destination for each terminal entry. If the 
terminals involved are non-polled terminals, a source macro must have been 
previously specified in the RCVHDR section of the LPS. 

Ex: ERRDEST 




84 



85 
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i 



When a message is canceled all references to ft are destroyed. 



H 



Write CANCELM in the Operation field of the next available macro statement 
in this section. 



I 



In the Operand field write the error mask for the desired error conditions, 
specified as X'mask', where mask represents the four-digit hexadecimal number. 

Ex: X'OOIO' 



T 



I Only one CANCEL statement is needed, since all error types requiring message 
I cancellation can be specified in the same error mask. 



i 



' Transmission of a message to a terminal can be halted and all further messages to 
I that terminal suppressed by use of an INTERCEPT macro statement. The intercept 
I of all messages to the terminal will occur when the error specified by the mask is 
I detected. The sequence number of the first untransmitted message for a terminal 
I will be stored in the INTERCPT optional field of the terminal table. 



"1 
,_l 

"1 

ion 




Write INTERCPT in the Operation field of the next macro statement in 
this section. 



EXAMPLE INTERCPT 



Name 



Operation 
INTERCPT 



Operand 



X'OOIO' 



In the Operand field write the error mask for the desired error conditions, 
specified as X'mask', where mask is a four-digit hexadecimal representation of 
the error mask. 

Ex: X'OOIO* 



T 



I Make sure that an optional field has been specified in the Terminal Table ' 

I (Section D) to receive the sequence number of the next message to be transmitted | 
I after an intercept. I 



i 



The send part of the LPS is now completely specified. To identify the end of the 
ENDSEND section, write the delimiter macro POSTSEND in the Operation field 
of the next macro statement. 



EXAMPLE POSTSEND 



Nc 



Operation 



POSTSEND 



Operand 



I The LPS is now finished except for one remaining item. i 

I Receive Segment LPS (Section G) must now be filled in. 



,:i" 



The number of character spaces to be reserved in the first buffer of an input 

message by the LPSTART macro depends on whether or not the first buffer of . 

I an input message is also the first buffer of an output message (e.g . , Message | 

I Switching Application). It this is the case, space must be reserved in the first | 

' buffer for both input and output — timestamp, datestamp, and sequence )ut ' 
I number. 
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87 



Yes 



Write In the Operand field of the LPSTART macro the decimal number equal to 
the sum of all the values assigned to the n parameters of the TIMESTAMP (in), 
TIMESTAMP (out), and SEQOUT macros, plus 7 bytes for each DATESTAMP (in) 
and DATESTAMP (out) macro used in the LPS for switched messages. 

Ex: 19 




Write in the Operand field of the LPSTART macro for this LPS the decimal number 
equal to the sum of the values assigned to the n parameters of all the 
TIMESTAMP (in) macros plus 7 bytes for each DATESTAMP (in) macro used in the 
LPS. 

Ex: 8 



» f < 



EXAMPLE LPSTART 



Name 



LPSl 



Operation 



LPSTART 



Operand 



19 



1 



For the reply of any messages that are generated by a user program, space 
must be reserved in the first buffer of the output message equal to the sum 
of the values of the n parameters for all TIMESTAMP (out) and SEQOUT macros I 
plus 7 bytes for each DATESTAMP (out) macro used in the LPS. I 




Repeat the LPS Sections starting at Receive Segment LPS Section G, being | 

careful that all sections of each LPS specified keep their identity. I 




All LPS macros have been specified at this point. The next section will be 
I concerned with specifying statements that will be used as initialization for the 
I Message Control Task. 




SECTION N. DATA SET INITIALIZATION 



*Terminals may be activated on a per-line or per- 
terminal basis, rather than by line group, by use 
of the CPYRL/CHNGPL or STRTLN/STOPLN macro 
instructions respectively. These macros may be 
included in the present section prior to, and 
immediately following, the OPEN macro instruc- 
tion{s) as required to provide the necessary control 
(see C28-6553), 




Write "Section N. Data Set Initialization" In the margin at the top of the 
next blank coding sheet. This will identify the macro statements for Section 



N. 



L 



The purpose of this section is to provide for specification of macros that will 
I initialize all Data Sets that will be referenced by the /VAessage GDntrol Task 
I and by use of OPEN and ENDREADY macros. 



■£ 



J 



When a Data Set is "opened", the following functions are performed: 

1 . Control blocks are initialized. 

I 2. Subroutines are acquired for the access method. 

I 3. Control blocks are assigned core storage locations. 

I 4. In the case of a communication line, the line will be made operative for 

' sending or receiving provided its polling list and terminal entries are 

I in an active status.* 



T 



Data Sets which will be referenced by the Message Control Task, and which 
I therefore must be "opened", are: 
I 1 . Communication Line Groups. 

I 2. Direct Access Storage Device used for queuing messages. 
I 3. External l/O device (s) used for logging messages. 

Each such Data Set has a Data Control Block (DCB) by which it is 
I referenced . 






X 



Opening of the Direct Access Storage Device, Logging Devices, and 
Communication Line Groups will now be provided for. 



JL 



.J 

n 
_j 



Write OPEN in the Operation field of the first macro statement for this 
section . 



EXAMPLE OPEN 



>.89[n2J 



Name 


Operation 


Operand 


STQTAM 


OPEN 


(DCBFILE,(INOUT),LOGFILE1, (OUTPUT), 






DCBGROUP,(INOUT)) 



88 



89 




Write In the Name field of this macro statement the symbolic name to be 
given to the Message Control Task. (The OPEN statement described Is 
considered to be the first statement of the MessageControl Task, This Is 
not necessarily the case, since other user coding, if specified, may precede 
the OPEN statement. In such a case it would be the first such statement that 
would have the name of the Message Control Task.) 

Ex: STQTAM 



First write in the Operand field of the OPEN macro a left parenthesis. 

Ex: ( 




In the Operand field, write the symbolic name of the Direct Access Storage Device 
DCB on which messages are to be queued, followed by a comma. 

Ex: DCBFILE, 



Next write In the Operand field the word INOUT, enclosed In parentheses, and 
followed by a comma. This specifies the direcr access device as both an "Input' 
and an "output" Data Set, 

Ex: (INOUT), 



-►< 



No 



Is there logging of messages 



""^s. on external l/u device(s) .■* ^^ 






Yes 






Write in the Operand field the symbolic name of a Logging device DCB 
defined in the Message Control Task, followed by a comma. 

Ex: LOGFILEl, 








V 






Next write in the Operand field the word OUTPUT, enclosed in parentheses, 
and followed by a comma. This specifies the direct access device as an "output" 
Data Set. 

Ex: (OUTPUT), 






J 




^X^ 




^^ Are there any 


more logging ^x.. Yes 

1 f . 1 • il . ^s_ 



3vice 



Message Control Task 
to be "opened" ? 



ra 
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No 



Write in the Operand field the symbolic name of a line group DCB in the 
system to be opened, followed by a comma. 

Ex: DCBGROUP, 



h 



N3jp.91 
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Next write in the Operand field the word INPUT, OUTPUT, or INOUT, 
whichever Is appropriate for the line group being "opened". For example, a 
line group that has both sending and receiving of messages would be specified 
as INOUT, whereas a line group that only received messages from terminals 
would be specified as INPUT. Precede the selected word with a left 
parenthesis. 

Ex: (INOUT 



I To specify that all lines in the communication line group being opened initially 

j be inactivated (In preparation for their later activation with the STRTLN 

j macro) an IDLE parameter may be specified in the OPEN macro statement. This 

j specification has the effect of issuing a STOPLN macro to each line. 



Yes 



Next write in the Operand field a comma followed by the word IDLE; 
followed by a right parenthesis. 

Ex: ,IDLE) 



Yes 



Write a comma In the Operand field following the last entry. 





Next write In the Operand field a right parenthesis, 
Ex: ) 



No 



* A final parameter may be placed in the Operand field 
of the OPEN macro statement specifying a parameter 
list that includes operand parameters for the OPEN macro. 
The purpose of this specification is to have a list of 
parameters that can be shared by many OPEN macro 
instructions. Sharing of the list is specified by writing 
a comma followed by MF=(E and another comma fol- 
lowed by the name of the parameter list. 

Ex: , MF=(E, LISTNAME) 
Specification of MF=E requires that an OPEN macro be 
included elsewhere (at the end) in the Message Control 
Task that has an MF=L specification. The name of this 
macro will be the name of the parameter list mentioned 
above. If neither MF=E nor MF=L is specified, the 
parameters specified in the OPEN macro instruction will 
be assembled "in line" and executed. For further 
description of the MF specification refer to IBM 
Operating System/360 Control Program Services 
(C28-6541). 



Complete the Operand specification for the OPEN macro by closing the 
parentheses following the last entry*. 

Ex: ) 



. If a subtask of the Message Control Task was defined in Section F and it is ' 

I desired to activate It only once, before receiving the first message into the j 

I system, the ACTSUBT macro instruction may be written at this point. This I 

I is in contrast to activating the subtask within the LPS structure, which would { 
' result in Its being activated each time the LPS sequence is passed through • 

(every message or message sequent). Deactivation of a subtask is accomplished I 



within the subtask itself by use of an ENDSUBT macro statement. 




Write in the Operand field the symbolic name of the subtask that was 
assigned to the subtask with its DENSUBT statement in Section F. 

Ex: SUBTl 



[nsJp. 
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EXAMPLE ENDREADY 



Write ENDREADY in the Operation field of the next macro statement 
for this section. This is essentially a WAIT type macro needed by the 
Message Control Task. The ENDREADY macro statement has no further 
parameters. 



Name 



Operation 



ENDREADY 



Operand 



^ 
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SECTION P. STRUCTURING 



Wp.92 

I All of the Message Control Task Sections of QTAM have now been completely 

I specified. Now it is necessary only to assemble the sections in the proper order. I 

1[_- 

To do this the user merely has to take the macro statements of the various sections I 
I and assemble them sequentially in the following order for each LPS specified: j 

I Section G. Receive Segment 

I Section H. Receive Header 

I Section J. End Receive . . p 

I Section K. Send Header 

. Section L. Send Segment , 

Section M. End Send ' | 



~T_ 



After assembling all sections of each LPS, each LPS must be assembled in sequence! 

I as shown below with the Data Set Initialization section placed at the head of the | 

I Assembly and all of the Data Set Definition and Control Information Sections I 

I placed at the end of the assembly. Order Is not Important within and-or between ' 
I the Data Set and Control Information Sections. 

I Section N. Data Set Initialization . 

I LPS! (Sections G-M) I 

I LPS2 (Sections G-M) j 
Section A. Communication Line Group DCB 

Message Control Task Section B. Direct Access Storage Device Queue DCB 

I Section C. Logging Device DCB . 

1 Section D. Terminal Table | 

I Section E. Polling List i 

1 Section F. Buffers ' 
I This assembly will be the desired Message Control Task. 

zizz zziziiTirzizzz zz z ^ 

' To incorporate this coding as the Message Control Task of QTAM within an i 

Operating System, the user is referred to IBM Operating System/360 Job I 
I Control Language (C28-6539). A brief checklist of other considerations 

I necessary for an operable communications systems is given here: . 

• Specification of message-processing tasks | 

I • Operator control messages and procedures I 

I • Activating and reactivating of communication lines ' 
I • Specification of Operating System/360 control cards 




94 



95 



APPENDIX A: SAMPLE PROGRAM 



The sample problem used here to illustrate the 
Queued Telecommunication Access Method will con- 
sist of three areas: 

1. Message Switching Application. A message 
switching application involves messages sent from a 
remote terminal that have as their destination 
another terminal or a group of terminals and require 
no intermediate processing. In this application, the 
following functions will be provided for: 

Receive 

a. Control 1050 communication terminals 
and lines 

b. Assemble messages received over 
communication lines 

c. Code convert messages from line code 
to internal EBCDIC code. 

d. Perform mess age -editing functions, 
such as time and date stamping, 
sequence number and source checking 

e. Route messages according to destination 
code to either single or multiple 
destinations 

f. Check for errors in messages 

g. Perform corrective action when errors 
are detected 

h. Perform queuing and logging of 

messages on a 2311 Disk Storage Drive. 
Send 

a. Insert sequence-out number of message 

b. Format message for transmission to 
terminal 

c. Code-convert message from the system 
EBCDIC code to the line code 

d. Address terminal and transmit message 

2. Inquiry Application. In the inquiry application 
described here, messages are sent from remote 
terminals that contain data to be processed, and a 
reply is sent back to the source terminal. A system 
data file is accessed by the processing program using 
an Operating System/ 3 60- supported access method. 
This file is on a 2311 Disk Storage Drive and is 
separate from the one used for the queuing of messages. 

In addition to those functions listed under mes- 
sage switching, an inquiry application must also provide 
for the following: 

a. Get message from the inquiry Process 
Queue 

b. Access file record 

c. Extract required information as 
indicated by message type 

d. Compute value specified by inquiry 
message 

e. Format reply message 

f. Put message into the message source 
destination queue 



3. Operator Control Program. In the operator 
control program described here, the control mes- 
sages are entered into the system through an in- 
house system terminal. These messages are sent 
either to modify the polling list or to inquire about 
the line or process queue. This operator control 
program consists of one main program and two 
subroutines. The main program will be permanently 
resident in core storage. The two subprograms will 
be linked by the main program. They will not 
necessarily be resident in core storage. 

In addition to functions a - g under message 
switching, an operator control program must also 
provide for the following: 

a. Get message from the Control Process 
Queue 

b. Examine message to determine type 

c. Link to the program that will handle the 
message type 

d. Operate on message request 

e. Format reply message 

f. Return to initial program 

g. Put message to the in-house terminal 
destination queue 

APPLICATION IMPLEMENTATION 

For these applications, certain functions are 
supplied by QTAM while other fimctions must be 
provided by the user. The functions listed under 
message switching and used by the other applications 
will be completely specified through the use of this 
manual and will be handled by QTAM. 

The remaining functions listed imder inquiry 
application and operator control program will be 
programmed as separate tasks. These tasks will 
be programmed like other processing programs 
in the system and are completely the responsibility 
of the user. QTAM does, however, supply certain 
macro instructions so that the needed programs can 
communicate with the main QTAM Task (Message 
Control Task). 

The QTAM Task, the Inquiry Task, and the 
Operator Control Task will all be assembled and 
executed through a normal job stream. Job control 
cards required by the job scheduler, such as JOB, 
EXEC, and DD statements, are not discussed here 
(see IBM Operating System/360 Job Control Language, 
C28-6539). 

SYSTEM CONFIGURATION 

The configuration of the system for the sample 
program is shown in Figure 1. Each device shown 
may be categorized into one of two groups. 
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CHI 



1050 



1050 



NYC 



BOS 



1050 



1050 



PHI 



OPR 



MPX Channel 



Model 
F 30 



Sel Channel 





Figure 1. System configuration for sample problem 
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For Communications: 



Inquiry Application 



6 1050 Data Communication Systems 

2 Half-Duplex Communication Lines 

1 Data Adapter Unit 

1 Multiplexor Channel 

1 2311 Disk Storage Drive 

For the Operating System: 
System/360, Model F30 (64K) 

1 Selector Channel 

1 1052 Console 

1 2311 Disk Storage Drive 

1 Printer 

1 Card Read Pimch 

JOB DEFINITION 



Inquiry messages require processing of the message 
by a problem program resident in the central proc- 
essing system. A reply message must be generated 
for transmission back to the sending terminal. The 
input message to be processed by the Inquiry routine 
must have the destination code INQ. The message 
entering the process queue (INQ) will have the date 
and time stamp inserted in the message header. The 
reply message generated by the inquiry processing 
program must contain the message tjqje code P in 
the outgoing message header format. This outgoing 
message tj^e will have inserted within the message 
header an out-date and time stamp and a sequence- 
out number. To allow for these insertions, 19 blank 
spaces must precede the first character of the reply 
message. . 



Each task difference and peculiarity is defined in the 
following paragraphs. 

Message Switching Application 



Switched messages (which require no processing of 
message text) are to be routed to their destinations. 
Destinations specified in the input header may be 
any of the following. 

• Single destination specified in the destination 
field of the header — for example, NYC. 

• Multiple destinations specified in sequence in 
the header — for example, NYC PHI. . . . 

• Distribution list specified in the header. For 
example, PDW would specify destinations 
contained in the terminal table list for PDW, 
that is, Philadelphia, Boston, Washington. 

The switched message, when sent to its destination, 
will have inserted in its message header the in-time 
stamp and in-date stamp, and a sequence-out number. 
Output niessages will be given priority over input, 
or received, messages. 



Operator Control Program 

Control messages require processing of the message 
by a problem program resident in the central proc- 
essing system. A reply message must be generated 
for transmission back to the in-house terminal (OPR). 
The message generated by the Operator Control 
program will have the destination code (OPR). The 
message entering the process queue (CTR) will have 
the date and time stamp inserted in the message 
header. These messages will be queued in main 
storage rather than on disk. The reply message is 
handled in the same manner as the Inquiry reply 
message. 

The message text format of a control message 
might be like one of the following: 

Text Function 

CHPL, LINEl, Stop polling line 1 

CHPL, LINEl, 1 Start polling line 1 

CHPL, LINE 2, Stop polling line 2 

CHPL, LINE2, 1 Start polling line 2 

CPYQ, LINEl Get line one queuing information 

CPYQ, LINE2 Get line two queuing information 

CPYQ, INQ Get INQ queuing information 

CPYQ, CTR Get CTR queuing information 
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MESSAGE FORMATS 

Figure 2 shows the message formats for the switched, 
inquiry, and control messages. The format of the 
messages is shown for both the receiving of the 
message from the terminal and the sending of the 
message or the reply to the terminal. 



Switched Message (in) 
Bytes T 2 3 4 5 



SWITCHED MESSAGE FORMATS 



192bCHI bNYCbPHI bPDW%*l TEXT 



EGA Seq in 



Dest 3 EOA Priority 



Switched Message (out) 
Bytes 12 3 4 5 



m))92bCHI bNYCbPHI bPDW%bl 1 ■30-45b64-285*lb83 TEXT 



EOA Seq in 



in dote stamp Priority Seq. out 



PROCESS MESSAGE FORMATS 



Process Message (in) 
Bytes 01 2345 6 78 9 10 1112 



2|l|3|b|c|H|l|b|l|N|Q|°/°| TEXT 



EOA Seq in 



Dest EOA 



Process Message (out) 
Bytes 01 2345 



Pb 21 3b CHI b bl 5 b1 3 I l-13b64-285 TEXT 



Msg Seq. in 

Type 



*Out time stamp 



Inserted by problem progr( 



Control Messoge (in) 
Bytes 1 4 



*Out date stamp 



CONTROL MESSAGE FORMATS 



01 1 bOPRb CTR%CHPL , L I NE1 ,0 



Reply generated by message Process Progr( 



Seq. in Source Dest Program to be used Parameter Li; 



Control Message (out) 
Bytes 



I ° I ^ i ' I ' U I b 1 1 1 1 |~T 



PbOllbOPRbb 



2 1 b 6 



3 2 4 TEXT 



Msg Seq. in 

Type 



•Out time stamp 



*Out dote stamp 



Reply generated by Control Progrc 



*Blank spaces are to be provided by the problem programs preceding the start of message equal In number to the total number of characters to be inserted in the sequence out, time stomp, and data stamp fields. This will be the 
new start of message. 



Figure 2. Formats for switched, inquiry, and control messages 
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PROGRAM FLOWCHART 

The following charts show the logic flow of the Line 
Procedure Specification portion of QTAM, the Inquiry 
Task, and the Operator Control Task. This is included 
for descriptive information only and does not necessarily 
represent the actual program logic flow of QTAM. 



V. 



Find the next messoge 

segment to be processed 

by either line 




TRANSLATE 
message segment to the 
common system wide code 




Skip the first character 
which is on End of Address 



Check the message 

sequence number to 

determine if it is correct 



Check the messoge source 
it Is a 3-letter code 



Route messoge to the 

destination identified 

by g 3-char. code 




Insert a 9-character 
time stamp 



Insert a 7-character 
dote stamp 



Determine message 
priority If any 



ENDRCVE 
-J^^^^<Wa$ EOM received?"' 





Send error message 
: terminal 



Send error message to 
source terminal and 
cancel the message 



Change polling pointer to 

next terminal on the 

polling list 



(Segment is processed ^ 
go to LPS 1 J 



NO_, 




< 


^^ header? ^^ 
^ YES 

message an Inquiry ^ 

^\^ type'P?^/^ 


I 




j[yes 




All message headers 
except type P messages 
will be handled here 




SKIPriie first 6 
non - blank characters 






* 




i 




Insert a 3-character 
sequence-out number 




Insert a S-character 
sequence-out number 












i 








Insert a 9-character 
time stamp 








I 








Insert a 7-character 
date stamp 








iJU 








SENDSEG " 








Insert 20 Idle characters 

ofter every carriage 

return character 






1' 






Translate message segment 
to the terminal code 






-*!' 



-J' 



Reroute message to the 
operator terminol 



POSTSENDJ' 



(Segment Is processed ^ 
go to LPSl J 
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Message Processing Program 




Determine what operation 
are needed to build a 
reply for the message 



Access r 

by the u 



eded files 



Build message reply 
leaving 19 spaces at the 
beginning for insertions 



Send reply to the message 

source terminal by the use 

of the PUT macro 
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Operator Control Message Processing Program 



GET message from 
CTL Process Queue 



CHPL 




Cancel Message J 



CPYQ 



Get the line identification 
from the message 



Get the line identification 
from the m essage 



Take line ID and search 

a table for proper 

DCB and rln 



Set bits to stop the 
pel ling of the line 




Set BITS so line 
will be polled 



Dynamically moke the 

CHNGPL macro 

instruction 



CHNGPL 



Return modified 
polling list 



Prepare a message to 

notify operator that the 

specified changes were 

made 



Prepare an error message 

to indicate wrong 

program name 



Dynamically moke the 
CPYQ macro instruction 



Send message to the dest. 

terminal (OPR) by the use 

of the PUT macro 



CPYQ 



Get queue information 
for line in work area 



Prepare queue information 
in message form 
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MACRO CODING 

The following pages illustrate the coding needed for 
each application. The Message Control Task, the 
coding of which is obtainable with this book, is 
completely coded. The Inquiry Application and the 
Operator Control Programs show methods of using 
the needed QTAM macro instructions and the over- 
all structure of the processing programs but do not 
show the actual program coding. 



Name 
STQTAM 



Operation 
OPEN 



MESSAGE CONTROL TASK OF QTAM 
Operand Comments 



(DCBFILE, (INOUT), 
DCBLINE, (INOUT), 
DCBOPRLG, (INOUT)) 



Data Set Initialization makes ready for use the 
Operator in-house terminal communication line and 
the direct access storage device used for message 
queuing. It causes polling to be initiated on the line, 
and updating of queue status tables. 



ENDREADY 



LPSl 



LPSTART 



19 



Receive Segment LPS Section — identifies the start 
of the LPS and reserves 19 spaces for the date stamp, 
time stamp, and sequence-out number at the beginning 
of the header segment. 



RCVSEG 



Instructions between this delimiter macro and the 
next will service both the header and the text seg- 
ments of the input message. 



TRANS 



RCVE1050 



Converts 1050 message characters to the common 
system- wide code EBCDIC. 



RCVHDR 



SKIP 



SEQIN 



,C'#' 



Receive Header LPS Section. Instructions between 
this delimiter macro and the next will service only 
the header segment of the input message. 

Causes all characters up to and including the # to be 
skipped, thus allowing the LPS to be in position for 
the first field (# is a translated (d) ). 



Checks sequence of numbered messages for each 
terminal as they arrive. No operand is needed since 
the sequence number is ended with a field delimiter 
character (blank). 



SOURCE 



Checks the validity of the source terminal code 
received in the message header against the code of 
the terminal that was polled. No operand needs to 
be specified since the field is ended with a field 
delimiter character. If the source code is invalid, 
an error is indicated in the error halfword of the 
line involved. 
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Name 



Operation 
ROUTE 



Operand 



EOA 



C'%' 



Comments 

Routes the message to the destination queue (s) 
specified in the message header and checks the 
validity of the destination code against the terminal 
table provided by the user. If the destination code 
is valid, the message is queued for the specified 
destination. 

Indicates that multiple destination routing is expected 
and must be checked for. The operand identifies % 
as the end-of-address character. This character 
must appear in the message header after the last 
destination code. 



TIMESTMP 



Inserts the time of day in the header field. First 
character is blank. The operand (9) indicates the 
number of characters to be inserted. 



DATESTMP 



MODE 



ENDRCVE 



EOBLC 



PRIORITY, C'*' 



Inserts the date in the header field. The insertion 
will consist of a blank character followed by a six- 
character date stamp. 

If the next character is an *, the character following 
the * will indicate the message priority. 

End Receive LPS Section. Macros between this 
delimiter macro and the next will service the message 
after the end of message is received. 

Allows the 1050 terminal to continue receiving after 
an EOB. It also provides for up to two retrans- 
missions of the message segment if a transmission 
error is detected. If the error is not corrected, an 
error is indicated in the error halfword for this line. 



ERRMSG 



X' 3 000', SOURCE, 
=C'bbb. MESSAGE 
NOT IN SEQUENCE' 



Sends the error text specified to the source terminal, 
when the error type specified by the mask is detected. 
The header of the message causing the error will be 
placed at the beginning of the text. The mask 3000 
is the bit configuration (in hexadecimal) used to test 
the halfword error indicator. 



ERRMSG 



X'8600'SOURCE, 
=C'bbb. MESSAGE 
HEADER FORMAT 
ERROR. CORRECT 
AND RE SEND' 



Sends the error text specified to the source terminal 
when the error tjrpe specified by the mask 8600 is 
detected. 



CANCELM 



X'8600' 



Message containing error indicated by mask 8600 
is canceled. 



POLLIMIT 



LIMIT 



Determines whether the terminal has sent the maxi- 
mum number of messages allowed on a single polling 
pass. The operand is the symbolic name of an 
optional field in the terminal table that contains the 
limit of consecutive polls for each terminal. 
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Name 



Operation Operand 

POSTRCVE 

SENDHDR 
MSGTYPE C'P' 



SKIP 



SEQOUT 



TIMESTMP 



DATESTMP 



MSGTYPE 



SEQOUT 



SENDSEG 



TRANS 



PAUSE 



SEND1050 



X'15',20X'17' 



Comments 

Delimiter macro which indicates the end of the 
receiving section of the LPS. 

Send Header LPS Section. Macros between this de- 
limiter macro and the next will service only the 
header segment of the output message. 

Message Type P Section. Determine whether the 
message is type P. If the next character is a P, the 
macros between this MSGTYPE macro and the next 
delimiter macro will handle these messages. The 
problem program must leave 19 spaces at the 
beginning of the inquiry reply message for the out- 
time stamp, date stamp, and sequence number. 

Causes 6 nondelimiter characters (sequence-in 
number and destination code) to be skipped to position 
the LPS for the first field. 

Sequentially number outgoing message by terminal. 
The operand (3) is the number of characters to be 
inserted (two digits preceded by a blank). Space 
must be reserved at the beginning of the message by 
the problem program for the sequence-out number. 

Inserts a 9-character time-of-day stamp in the out- 
going header field. (The first of the 9 characters is 
a blank. ) 

Inserts a 7 -character date stamp in the outgoing 
message header. The first character is a blank, 
followed by a 6-character date stamp. 

Remaining Message Type Section. All messages 
except type P messages wUl be handled by the macros 
between this MSGTYPE macro and the next de- 
limiter macro (SENDSEG). 

Sequentially number outgoing messages by terminal. 
The operand (3) indicates that a three-character 
output sequence number is to be inserted (two digits 
preceded by a blank). Space must be reserved by 
the use of LPSTART for message-switching messages. 

Send Segment LPS Section. Macros between this 
delimiter macro and the next will service both the 
header and the text segments of the output message. 

Translates output message using code conversion 
table name SEND1050. 

Upon recognition of each carriage return character 
(X'15'), this routine will insert 20 idle characters 
(X'17') to provide time for the carriage to return. 
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Name 



Operation 

ENDSEND 

EOBLC 



Operand 



REROUTE 



POSTSEND 



DCBLINE DCB 



DCBOPRLG DCB 



DCBFILE DCB 



TERMTBL 



X'0040',=C'OPR' 



DDNAME 
=DDGROUPl, 

DSORG=CX, 

MACRF=(G, P), 

CPOLL=(POLLINEl, 
POLLINE2), 

BUFRQ=2, 

ACLOC=13, 

CLPS=LPS1 



DDNAME 

=DDGROUP2, DSORG 
=CX, MACRF=(G, P), 
CPOLL-(POLLINE3), 
BUFRQ=2, ACLOC=13, 
CLPS=LPS1 

DDNAME=DDFILE, 



DSORG=CQ, 
MACRF=(G, P) 
PBW, 3 



Comments 

END SEND LPS SECTION. Macros between this 
delimiter macro and the next define functions to be 
performed after the message has been sent. 

Informs QTAM to continue sending upon recognition 
of an FOB. It also specifies retransmission of a 
message segment if a transmission error is detected. 
If the error is not corrected, an error is indicated 
in the error half word for this line. 

Causes a message to be queued for the terminal name 
OPR when the error type specified is detected. 

Delimiter macro which identifies the end of the sending 
portion of the LPS. It also indicates the last instruction 
of this LPS. 

Commvinication Line Group DCB Section — identifies 
DD statement name associated with this DCB. 

Define DCB as a communication line group type. 

I/O access level is GET/PUT. 

Symbolic names assigned to the polling list of the 
two lines. 

Number of buffer requests required by each line. 

Relative position of the selecting address of terminals 
within its terminal table entry (see terminal table 
entry format). 

Identifies LPSl as the name of the LPS for these two 
lines. 

Identifies the operator in-house terminal line group. 



Direct Access Device Queue DCB Section — identifies 
DD statement associated with this DCB. 

Defines DCB as a direct access device type. 

Queue to be accessed at the GET/PUT level. 

Terminal Table Section — specifies the extent of the 
terminal table. PBW is defined as the last entry in 
the terminal table. 
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Name 
LIMIT 



Operation 
OPTION 



Operand 
FLl 



Comments 

Limit is the symbolic name of the field in this terminal 
table which contains the limit of consecutive polls for 
each terminal. 



CHI 


TERM 


L, DCBLINE,!, 
6407640D, (3) 


NYC 


TERM 


L, DCBLINE, 2, 
6207620D, (3) 


PHI 


TERM 


L, DCBLINE, 2, 
6407640D, (2) 


BOS 


TERM 


L, DCBLINE, 1, 
6207620D, (2) 


WAS 


TERM 


L, DCBLINE, 2, 
6707670D, (1) 


OPR 


TERM 


L, DCBOPRLG, 
6207620D, (5) 



INQ 



CTR 



PROCESS 



PROCESS 



EXPEDITE 



The six terminals and their parameters are here 
defined. L indicates outgoing messages are to be 
queued by line; DCBLINE is name of associated DCB; 
1 is relative line number within the line group; 6407 
is 1050 addressing code; 640D is 1050 polling code; 
the number in parentheses defines the maximum 
number of consecutive polls for each terminal to be 
inserted in the LIMIT field defined above. 



Defines the symbolic names of the process queues in 
the terminal table, thus allowing INQ and CTR as 
valid destinations. 

The CTR queue will be in main storage since EXPEDITE 
was used. 



PBW 



LIST 



POLLINEl POLL 



POLLINE2 POLL 



(PHI, BOS, WAS) Define a distribution list of message destinations as 

PHI, BOS, WAS. 



(CHI, BOS) 



Polling List Section — defines order of polling of 
terminals attached to line 1. 



(NYC, PHI, NYC, WAS) Defines order of polling of terminals attached to 

line 2. 



POLLINE3 POLL 



BUFFER 



STPROCES 



OPEN 



(OPR) 



DCBFILE,10,95 



Defines polling of the operator in-house terminal line. 
Polling is initiated upon execution of the open for the 
line group. 

Buffer Section — provides internal storage buffering 
for the DCBFILE used for message queuing. Ten 
buffers are specified with 95 bytes per buffer. 



INQUIRY MESSAGE PROCESSING TASK OF QTAM 



(PROCESSQ) 



Opens the message control queue (INQ) so that 
messages can be obtained from the queue by the use 
of a GET macro instruction. 



OPEN 



(REPLYQ) 



Opens the output DCB; this causes a linkage to the 
Message Control Task so that the PUT macro 
instruction can send messages to their destination. 



LOOP 



GET 



PROCESSQ, WORKAl 



Queue Access Section, Get the next sequential 
segment from the queue (INQ) referenced by the DCB 
and place it in work area WORKAl. If no segments 
are available, a WAIT it implied. 
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(The message is now available for processing by the problem program. References to files for data to be 
used in preparing the reply, if required, would be \mder normal procedures of Operating System/360, ) 



Name 



Operation 
PUT 



B 



WORKAl 


DS 


WORKA2 


DS 


SOURCE 


DS 



PROCESSQ 



DCB 



REPLYQ 



DCB 



Operand 
REPLYQ, W0RKA2 

LOOP 

CLIOO 
CLIOO 
CL3 

DDNAME=INQ, 

MACRF^G, 
BUFRQ=2, 

SYMAD=ERROR, 
TRMAD==SOURCE, 

DSORG=MQ, 

SOWA=100, 

RECFM=S 



Comments 

Place the processed message on the appropriate 
destination queue specified by the reply DCB parameter 
TRMAD. The terminal table entry name in the 
location specified by TRMAD will be the destination. 

Branch to beginning to "GET" next message for 
processing. 

Define work areas. 



Defines a 3-character area referred to by the TRMAD 
parameter of the DCB. It will contain the message 
destination Terminal Table entry name. 

Process Program Queues DCB Section (Type 1) — name 
of the Process Queue Terminal Table entry name and 
associated DD statement for this process DCB, 

Program at the GET level. 

Two buffers will be queued ahead in core from the 
direct access device queue. 

Name of routine that will handle overflow of messages. 

Specifies the name of the location that will contain 
where the message came from in the case of a GET 
macro, and the message destination in the case of 
a PUT macro. 

Defines DCB as a process program type. 

Work area size (in b5^es). 

Working imit is a segment. 



DDNAME=DDREPLY, Process Program Queues DCB Section (Type 2). 
MACRF=P, 



TRMAD=SOURCE, 
DSORG=MQ, 
SOWA=100, 
RECFM=G 



Refer to PROCESSQ DCB for explanation of parameters. 
RECFM=G means that the complete messages are 
being PUT to the destination. 
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Name Operation 

STOPRTOR OPEN 

OPEN 



OPERATOR CONTROL TASK OF QTAM 
Operand Comments 



NEXT 



GET 



(PRCDCB) 



(RPLYDCB) 



PRCSDCB, WORKAl 



OPENS the message control queue (CTR) so that 
messages can be obtained from the queue by the use 
of a GET macro instruction. 

OPENs the output DCB; this causes a linkage to the 
message control task so that the PUT macro instruction 
can send messages to their destination. 

Get the next sequential message segment from the 
queue (CTR) and place it in the work area. 



(Determine which subprogram the message requests and LINK to it. The program that is linked will do the 
compilation required to accomplish the request. The program will execute CPYPL, CHNGPL, and CPYQ 
macros as required. The linked program will then prepare a reply for the operator and place it in WORKA.2 
and return to the main program. ) 



PUT 



B 



WORKAl 


DS 


WORKA2 


DS 


SOURCE 


DS 



•DEST 



PRCSDCB 



DS 



DCB 



RPLYDCB DCB 



RPLYDCB, WORKA2 Sends the reply message to OPR. 



NEXT 

CLIOO 
CL200 
CL3 



C'OPR' 



DDNAME^CTR, 

MACRF=G, 

BUFRQ=2, 

SYNAD=ERROR, 

TRMAD=SOURCE, 

DSORG=MQ, 

SOWA=100, 

RECFM-S 

DDNAME^DDRPLY, 

MACRF=P, 

TRMAD=DEST, 

DSORG^MQ, 

SOWA=200, 

RECFM=G 



GET next message from queue, or wait imtil next 
message enters the queue. 

Define work ar6as . 



Provide area that will contain the source terminal 
entry name. The name will be examined by the operator 
control program to see if it is OPR. If not, the 
message will be canceled (see program logic flow). 

Provide the destination terminal entry name. All 
replies will then go to this terminal (OPR) when a 
PUT macro references the DCB named REPLYDCB. 
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APPENDIX B: MESSAGE HEADERS FOR QTAM 



A message header is a prefix to a message received 
or sent via com.munication lines containing infor- 
mation for: 

Routing of the message 

Sequence numbering 

Source validity checking 

Time stamping 

Date stamping 

Priority assignment 

Identification of message type 

Specification of special user functions 
The message header may contain other information 
not of immediate use for handling of the message — 
for example, various device- required characters, 
identification fields for operator use, or fields 
required for later processing of the message. 

A particular telecommunications system appli- 
cation using QTAM may have all or none of this 
information in the message headers, depending on 
the desired flexibility of the system and the functions 
to be performed. 

QTAM provides a flexible, high-level macro 
language that can be used to specify header analysis 
procedures for nearly all reasonable message headers 
and supported communications equipment. This 
document describes desirable and necessary features 
for message headers being analyzed by QTAM. 

In general, message headers are for input messages 
(messages received from terminals via communication 
lines), output messages (messages sent to terminals 
via communication lines), or both, as in the case of 
a message-switching application where the same 
header (and text) is sent as is received, except for 
additions made by the QTAM program. 

Message headers change in appearance as they 
proceed through, and are operated on by, various 
parts of the communications system. The following 
discussion is concerned only with the message 
headers as they are prepared at the terminal for 
sending. 

A number of considerations should be made when 
preparing message header formats designed for 
easy and efficient use of QTAM: 

• Line control characters. Depending on the 
particular terminal device and communication 
line control discipline used (for example, 
Telet3^e 28ASR terminals in an 83B2 control 
system), particular control characters or 
sequences of characters will be needed in the 
message header. The actual characters used 
are very device-dependent and will not be 
covered here. To determine what these 
characters are for a particular system, it is 
best to consult manuals describing the par- 
ticvilar devices used. 



Just who is responsible for placing specific 
control characters in a message header also 
depends oii the devices used. Usually it is a 
shared responsibility of both the person pre- 
paring the message and the terminal device 
used to transmit it. * This information is also 
to be derived from the manual for the particular 
devices involved. 

Header field definition. The content of a mes- 
sage header is contained within "fields" 
consisting of one or more characters each 
(Figure 3), Each such field contains information 
for a particular operation or function to be 
performed on that message (header and text). 



Msg Type 
Field 



Input Sequence 
Number Field 



Message 


Message 


Dest. 1 


Dest. 2 


Field 


Field 



Figure 3. Example of message header fields 

• Fixed or variable length. Message header fields 
must in general be of a fixed length for each 
particular field. Exceptions to this are 

(1) source and destination fields of a message 
that may consist of any number of characters 
up to a maximum of eight bytes (characters), 
and (2) input sequence number fields, which 
may be any length up to five bj^es containing 
four digits (the first byte is always blank). 

• Field separation. Header fields may be 
separated by any number of blank characters. 
If blank characters are used to separate the 
fields, the length of the fields need not be 
specified in the QTAM macros. For variable- 
length fields (as discussed above) blank charac- 
ters must be used to delineate the field, since 

a fixed length cannot be specified. If fields 
are not separated by blank characters, the 
exact length of each field must be specified. 

• Order of fields within header. In message 
headers for a message -switching application 
using QTAM, all fields concerned with receiving 
the message must precede those concerned 
with sending it (Figure 4). 

Message Header 



Receive Fields 



Message Text 



Figure 4. Order of header fields for message switching 

*The same is true for reception of the message by the CPU. Certain 
control characters will be deleted by the control luiit and others 
will be passed through to be handled by the QTAM program. 
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• Header length. The length of the message 
header must be less than or equal to that of 
the buffer length specified in the QTAM macro 
program, minus 32 bytes used for the header 
prefix. Conversely, when specifying the 
macro program for QTAM, the length of the 
buffers specified must be sufficient to contain 
the maximum message header plus 32 bytes 
for the prefix. 

• Message type identification. Message headers 
that require different handling procedures or 
have different formats from other messages 
on a line may be identified by a special 
character or sequence of characters. It is 
desirable that this "message t5^e" identification 
be the first field of the message header. This 
makes possible early separation of the various 
types of messages involved so that the proper 
procedure can be followed by each. 

• Skipping unwanted fields. Fields that are not 
checked or used by header analysis may be 
skipped by either specifying within the QTAM 
macros the number of nonblank characters in 
the field to be skipped or by identifying the 
end of the field by a special character con- 
figuration in the message header. This 
configuration can be from one to eight nonblank 
characters in length. (See Figure 5. ) 



Identification 



Used Field 


^_^ 












Field t 
(Nc 


o be Skipped 
tJJsed) 








of End 
Fi< 
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■ 
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p 
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!■= 


« 


' 


1- 


X 
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t, 





Figure 5. Skipping a variable-length field 

• Message priorities. Priority of a message can 
be identified by either a special character in 
the message header followed by the message 
priority or by just specifying the message 
priority. A special character should be used 
when all messages are not necessarily given 
a priority, while the second case can be used 
when a priority is inserted in every message. 

Message priority levels range from 1, 2, , 

9, A, B, , Y, Z, where Z is the highest 

priority and 1 is the lowest. 



• Destination fields. When multiple destinations 
are desired in the message header, a special 
character or sequence of characters must be 
reserved to identify the last destination 
(address) listed. This character(s) is termed 
the end of address (EOA) character(s). Each 
destination may be separated by a blank 
character (s) from the others. If this is done, 
the length of each destination will not have to 
be specified within the QTAM macro program, 
and the destinations may then be variable in 
length (Figure 6). 



CHI NYC .BOSTON WASH (a 



Figure 6. Multiple destination fields of variable length 

If there is never more than one destination, 
the End of Address field is not needed, and if 
the destination is fixed it does not even have to 
be included in the message header. 

• Special handling. A special character may be 
placed in the message header to specify that the 
message is to be handled in the "initiate" mode. 
When a message is handled in the "initiate" mode, 
message segments may be either processed or 
sent to a destination before the entire message 

is received. The special character is needed 
only when not all of the messages of a given 
type are to be handled in this mode. 

• Conversational mode. A special character may 
also be placed in the message header to identify 
that the message is to be handled in "conver- 
sational" mode. Receipt of a message in this 
mode will imply that the next terminal on the 
line will not be "polled" imtil a further exchange 
of messages has occurred. The special 
character is needed only when not all of the 
messages operate in this mode. 

• User routines . Just as for the "initiate" and 
"conversational" modes, a user routine can be 
specified to operate only on certain messages 
containing a special character. Again, this 
special character is needed in the message 
header only if not all messages require the 
particular user routine. 
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